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FOREWORD 


1 .  This  military  handbook  is  approved  for  use  by  all  Departments  and  Agencies  of  the 
Department  of  Defense. 

2.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any  pertinent  data  which 
may  be  of  use  in  improving  this  document  should  be  addressed  to:  Commander,  US  Army  Missile 
Command,  ATTN:  AMSMI-RD-SE-TD-ST,  Redstone  Arsenal,  AL  35898-5270,  by  using  the 
self-addressed  Standardization  Document  Improvement  Proposal  (DD  Form  1426)  appearing  at 
the  end  of  this  document,  or  by  letter. 

3.  The  purpose  of  this  document  is  to  provide  human  factors  engineering  design  guidance  for  the 
analysis,  design,  and  evaluation  corr.putor  based  ManagernKut  information  Systems.  Guidance 
is  presented  in  the  form  of  1)  analysis  and  design  techniques  which  should  be  applied  to  the 
development  and  evaluation  of  User-Computer  Interface  (UCI)  design  concepts,  and  2),  design 
guidelines  which  should  be  used  during  UCI  requirements  analysis,  design,  development,  test  and 
integration. 
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1.  SCOPE 

1.1  Purpose.  The  purpose  of  this  handbook  is  to  provide  guidance  in  the  application  of  human 
engineering  to  the  design  and  development  of  management  information  (and  related)  software 
systems.  The  users  of  this  document  are  intended  to  be  any  individual,  or  group,  who  participates 

in  the  development  of  software  systems,  including  logicians,  software  engineers,  end-system  users, 
software  development  managers,  programmers,  system  evaluators,  and  human  factors  engineers. 

1 .2  Scope.  This  handbook  provides  analysis  techniques  and  methodologies  for  management 
information  system  development  and  presents  human  engineering  guidelines  for  detailed 
user-computer  interface  software  design.  Where  hardware  design  guidance  is  needed,  the 
requirements  of  MIL-STD-1472  "Human  Engineering  Design  Criteria  for  Military  Systems, 

Equipment,  and  Facilities"  should  apply. 
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2.  APPLICABLE  DOCUMENTS 


2.1  Government  documents. 

2.1 .1  Specifications,  standards,  and  handbooks.  The  following  specifications,  standards,  and 
handbooks  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise  specified, 
the  issues  of  these  documents  are  those  listed  in  the  issue  of  the  Department  of  Defense  Index  of 
Specifications  and  Standards  (DODISS)  and  supplement  thereto,  cited  in  solicitation. 

SPECIFICATIONS 


MILITARY 


MIL-H-46855B 

STANDARDS 

MILITARY 

MIL-STD-12 

MIL-STD-411 

MIL-STD-490 

MIL-STD-783 

MlL-STD-1472 

MIL-STD-2167 

HANDBOOKS 

MILITARY 

MIL-HDBK-759 

MIL-HDBK-763 


Human  Engineering  Requirements  for  Military  Systems, 
Equipment,  and  Facilities. 


Abbreviations  for  use  on  Drawings,  Specifications, 
Standards,  and  in  Technical-Type  Publications. 

Aircrew  Station  Signals. 

Specification  Practices. 

Legends  for  Use  in  Aircrew  Stations  and  on  Airborne 
Equipment. 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment,  and  Facilities. 

Defense  System  Software  Development. 


Human  Factors  Engineering  Design  for  Army  Material. 
Human  Engineering  Procedures  Guide. 


2.2  Non-Government  publications.  The  following  document(s)  form  a  part  of  this  document  to 
the  extent  specified  herein.  Unless  otherwise  specified,  the  issues  of  the  documents  which  are  DoD 
adopted  are  those  listed  in  the  issue  of  the  DODISS  cited  in  the  solicitation.  Unless  otherwise 
specified,  the  issues  of  the  documents  not  listed  in  the  DODISS  are  the  issues  of  the  documents  cited 
in  the  solicitation. 


AMERICAN  NATIONAL  STANDARDS  INSTITUTE 


ANSI/HFS  1 00- 1 988  Visual  Display  T erminal  Workstations. 

2.3  Order  of  precedence.  In  the  event  of  conflict  between  the  text  of  this  handbook  and  the 
specifications  and  standards  cited  herein,  the  text  of  standards  and  specifications  should  take 
precedence.  In  the  event  of  conflict  between  the  text  of  this  handbook  and  military  handbooks  cited 
herein,  the  text  of  this  handbook  should  take  precedence. 
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3.  DEFINITIONS 


3.1  Definition  of  terms. 

3.1.1  Management  information  system.  A  system  which  may  perform  routine  processing 
functions,  but  which  is  designed  so  that  processing  will  produce  information  that  will  assist  in 
decision  making.  Real-time  processing  of  information  is  frequently  required  in  management 
information  systems. 

3.1.2  Human  engineering.  A  technical  discipline  which  exists  to  optimize  overall  system 
performance  through  development  of  compatible  interactions  between  the  human  and  the  system,  in 
order  to  reduce  human  contributions  to  system  unreliability,  non-availability,  and  mission 

failure. 

3.1.3  User-computer  interface.  The  modes  by  which  the  human  user  and  the  coi  I  ipui6r 
communicate  information  and  by  which  control  is  commanded,  including  areas  such  as;  information 
presentation,  displays,  displayed  information,  formats  and  data  elements;  command  modes  and 
languages:  input  devices  and  techniques:  dialog,  interaction  and  transaction  modes:  timing  and 
pacing  of  operations;  feedback,  error  diagnosis,  prompting,  queuing  and  job  performance  aiding; 
and  decision  aiding. 

3.2  Abbreviations  and  acronyms  used  in  this  handbook.  Definition  of  abbreviations  and 
acronyms  used  in  this  handbook  are  as  follows: 


CPU  - 

Central  Processing  Unit 

cs:  - 

Computer  Software  Component 

CSCI  - 

Computer  Software  Configuration  Item 

FCA  - 

Functional  Configuration  Audit 

FGR  - 

Formal  Qualification  Review 

l-E 

Human  Engineering 

HFE  - 

Human  Factors  Engineering 

I/O  - 

Input/Output 

JPA  - 

Job  Performance  Aid 

MIS  - 

Management  Information  System 

PCA  - 

Physical  Configuration  Audit 

PDR  - 

Preliminary  Design  Review 

SRR  - 

System  Requirements  Review 

SDR  - 

System  Design  Review 

TRR  - 

Test  Readiness  Review 

UCI  - 

User-Computer  Interface 

VDT  - 

Visual  Display  Terminal. 
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4.  GENERAL  GUIDANCE 


4.1  Design  process. 

4.1 .1  Overview.  DOD-STD-2167  Defense  System  Software  Development  describes  the  software 
development  process  and  the  significant  activities  required  in  each  phase  of  that  process. 
DOD-STD-21 67  does  not  specifically  address  the  development  of  the  user-computer  interface  in 
conjunction  with  the  development  of  system  software,  however,  a  process  for  developing  and 
evaluating  UCI  for  a  software  system  should  be  closely  integrated  with  the  process  for  overall 
software  development.  UCI  design  will  place  additional  requirements  and  constraints  on  overall 
software  design.  Therefore,  the  design  of  UCI  must  be  integrated  into  the  software  development 
process.  As  defined  in  DOD-STD  2167,  the  major  phases  in  the  software  development  process,  and 
the  reviews  conducted  at  the  termination  of  each  phase,  are  as  follows; 

a)  System  concept  development  -  system  requirements  review 

b)  System  requirements  analysis  -  system  design  review 

c)  Software  requirements  analysis  -  software  specification  review 

d)  Preliminary  design  -  preliminary  design  review 

e)  Detailed  design  -  critical  design  review 

f)  Coding,  unit  testing  and  computer  software  component  integration  testing  - 
test  readiness  review 

g)  System  integration  and  testing  (including  computer  software  configuration  item 
testing)  -  functional  configuration  audit ,  physical  configuration  audit,  and  formal 
qualification  review. 

UCI  incorporates  all  system  design  features  and  provisions  which  enable  and  enhance  the 
interactions  between  the  system  user  and  software.  These  include;  displays,  displayed  information, 
formats  and  elements:  command  modes;  user-interface  language:  input  devices  and  techniques; 
dialogs,  interactions  and  transactions  between  user  and  computer;  user  feedback;  decision  aiding; 
procedures  and  user  documentation;  and  provisions  for  training,  prompting,  cueing,  helping, 
tutoring,  and  job  performance  aiding.  The  objective  of  the  UCI  design  process  is  to  describe  a 
standardized  and  formalized  approach  to  the  design  of  user-computer  interfaces  which,  used  in 
conjunction  with  the  guidelines  in  Section  5  of  this  Handbook,  will  result  in  a  UCI  approach  which 
is  maximally  usable,  operable,  reliable  and  fully  integrated  with  the  system  and  software 
development  processes. 

The  basis  of  the  approach  in  the  UCI  design  process  is  to  identify  user  requirements  and  UCI 
design  concepts  and  criteria,  and  to  integrate  these  with  the  overall  software  development  effort. 

The  UCI  design  process  consists  of  three  distinct  phases;  requirements  analysis,  UCI  design  and 
development,  and  UCI  test  and  integration. 

The  primary  products  of  the  UCI  design  process  are  the  outputs  of  each  of  the  process  phases. 
These  are;  a  functional  specification,  describing  the  requirements  which  the  UCI  design  will 
address;  a  design  specification  describing  the  design  approaches  to  be  taken  in  UCI  design;  an 
implementation  specification,  describing  how  the  UCI  must  be  implemented:  and  UCI  test  and 
evaluation  plans  and  reports. 

4.1.2  Description  of  the  UCI  design  process.  Figure  1  presents  the  overall  UCI  design  process 
integrated  with  the  overall  software  development  process  as  outlined  in  DOD-STD-2167. 
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PHASE  I:  REQUIREMENTS  ANALYSIS 


PROGRAM 

PLAN 


Identify: 

Design  Constraints 
Design  Activities 
Schedules  and  Milestones 
Resource  Requirements 
Prepare  Program  Plan 


USER  NEEDS 
ANALYSIS 


UCI 

FUNCTIONAL 

SPECIFICATION 


Analyze: 

Missions/Functions 
Comparable  Systems 
User  Roles/Requirements 
Task  Requirements 


List  UCI  Design 
Requirements  by  task 
Consolidate/Synthesize 
Requirements 
List  and  Package  UCI 
Requirements 


PHASE  II:  UCI  DESIGN  AND  DEVELOPMENT 


UCI 

CONCEPTS 


Develop  Concepts: 
Screens/displays 
Interaction/Transaction 
Use  Procedures 
Decision  Aids 


UCI  DESIGN 
ST'JDIES  AND 
TRADE-OFFS 


UCI 

DESIGN 

SPECIFICATION 


Conduct  Simulations 
Develop  Trade-off  Criteria 
Conduct  UCI  Design  Trade-offs 


Specify  Design  Criteria: 
Displays 
Dialog 
Job  Aids 
etc. 


PHASE  III:  TEST  AND  INTEGRATION 


DESIGN 

VERIFICATION 


Conduct  Verifications: 
Displays 
Dialog 

Transaction  Control 
Procedures 


USER 

ACCEPTANCE 

TESTS 


Individual  User 
Controlled  Tests 
Small  Group  Controlled 
Tests 
Field  ■’"ests 


DESIGN 

INTEGRATION 


I 


UCI 

IMPLEMENTATION 

SPECIFICATION 


Develop  Integration  criteria 
Integrate  Design  Features 
Integrate  Procedures 


Specify: 

UCI  Procedures 
T  raining 

User  documentation 
Implementation 
Requirements 
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4.1 .2.1  Phase  I:  requirements  analysis.  The  objecti>/e  of  this  phase  is  to  produce  the  UCI 
functional  specification,  which  contains  the  set  of  requirements  which  the  UCI  design  approach 
will  address.  During  this  initial  Phase  the  UCI  Design  Program  Plan  is  prepared  and  published. 

When  the  plan  has  been  implemented,  the  next  step  is  the  conduct  of  the  user  requirements 
analysis,  which  is  primarily  concerned  with  defining  system,  user,  function  and  task 
requirements.  Lessons  learned  from  existing  systems  are  examined  to  identify  pitfalls  to  be 
avoided  and  effective  design  approaches  to  be  continued  in  the  emerging  system.  Eased  on  the  set  of 
requirements  and  lessons  learned,  specific  functional  requirements  for  the  UCI  will  be  developed 

in  terms  of  the  capabilities  which  the  UCI  must  pxDssess  in  order  to  support  the  performance  of 
each  task.  These  functional  requirements  will  form  the  basis  for  the  UCI  functional  specification. 

The  major  products  of  this  phase  are  the  lessons  learned,  user  tasks  and  task  requirements,  and 
the  UCI  functional  specification,  keyed  to  user  tasks.  Activities  in  this  phase  of  UCI  development 
are  conducted  in  the  System  Concept  Development  and  System  Requirements  Analysis  Phases.  The 
UCI  functional  specification  will  serve  as  an  input  to  the  system  segment  specification,  the 
operational  concept  document  and  the  preliminary  interface  requirements  specification.  The 
importance  of  Phase  I  for  UCI  design  is  that  successful  completion  of  Phase  I  activities  will  ensure 
that;  user  requirements  and  capabilities  are  considered  early  in  the  system  design  effort;  UCI 
implementations  will  be  usable  by  the  range  of  intended  users;  and  the  resulting  system  design 
will  be  more  operable,  more  reliable,  current,  usable,  and  affordable. 

4. 1.2. 1.1  UCI  design  task  1  -  prepare  program  plan 

a)  Objective.  The  objective  of  this  step  is  to  describe  the  process  for  producing  a  program 
plan  for  the  UCI  design  effort. 

b)  Approach.  The  approach  to  developing  a  UCI  design  program  plan  involves  the  following 
efforts: 

1 )  Identify  UCI  design  activities  applicable  to  each  phase  of  system  development, 
relying  on  this  description  of  the  UCI  design  process  and  its  associated  design 
activities. 

2)  Identify  schedules  and  milestones  associated  with  the  conduct  of  the  UCI  design 
activities.  Schedules  will  be  adapted  from  the  overall  system  development 
schedule  and  will  be  associated  with  the  software  development  activities. 

Milestones  will  be  the  specific  steps  of  the  UCI  design  process. 

3)  Identify  required  resources,  including  data,  funding,  instrumentation,  computer 
resources,  special  facilities  such  as  rapid  prototyping  capabilities,  and 
personnel,  by  area  of  expertise,  who  will  participate  on  the  UCI  design  team. 

Areas  of  expertise  should  include  human  factors  engineering,  computer 
programming,  engineering,  and  user  requirements  determination. 

4)  Produce  the  program  plan  addressing  each  phase  of  system  development. 

c)  Product-  The  UCI  Design  Program  Plan  and  specific  inputs  to  the  software  development 
plan. 
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4.1 .2.1 .2  UCI  design  task  2  -  user  n.ccds  analysis 

a)  Objective.  To  identify,  analyze  and  integrate  user  requirements  which  will  drive  UCI 
design  . 

b)  Approach.  The  activities  to  be  conducted  in  the  user  needs  analysis  are  as  follows: 

1 )  Analysis  of  missions  and  functions  -  Missions  will  be  identified  and  a  mission  profile 
will  be  constructed.  This  profile  will  segment  the  mission  into  discrete  and  well  defined 
mission  phases.  Mission  conditions  will  be  described  which  will  include,  at  a  minimum, 
operational  conditions  such  as  normal,  contingency,  and  emergency  operation.  For  each 
mission  phase  under  each  mission  condition,  a  sequence  of  top-level  functions  will  be 
identified.  These  functions  include  the  actions,  and  sequence  of  actions,  required  for  the 
system  (user,  hardware  and  software)  to  complete  each  mission  phase.  The  functions  will 
be  iteratively  analyzed  to  lower  levels  of  specificity.  An  example  of  a  UCI  functional 
analysis  form  is  presented  as  Figure  2.  Table  1  contains  descriptions  and  examples  of  the 
type  of  data  to  be  entered  in  using  this  form. 

2)  Comparability  analysis  -  UCI  designs  implemented  in  existing  systems  performing 

the  functions  identified  aboye  will  be  assessed.  UCI  lessons  learned  will  include:  problems 
with  UCI  usability;  p>ositiye  aspects  of  the  UCI  design  which  should  be  retained;  and  lessons 
learned  in  UCI  design,  deyelopment  and  implementation. 

3)  Role  of  the  user  analysis  -System  functions  will  be  assessed  and  criteria  developed,  b 
based  on  human  and  machine  capabilities  and  limitations,  to  determine  which  should 

be  automated,  which  should  be  manual,  and  which  should  require  an  interaction  between 
user  and  software.  The  role  of  the  user  addresses  the  human  performance  requirements 
for  all  functions. 

4)  Task  analysis  -For  each  mission  and  function  under  each  mission  condition,  user  tasks 
and  task  sequences  will  be  identified.  Task  requirements  will  be  identified  as:  information 
requirements  -  information  required  to  support  the  performance  of  each  task,  and 
characteristics  associated  with  the  information;  performance  requirements  -  criteria  for 
each  task,  such  as  accuracy  limits,  time  constraints,  workload  limits,  required 
throughput,  and  error  tolerances:  decision  requirements  -  decisions,  decision  rules, 
options  and  feedback  requirements  associated  with  the  performance  of  each  task;  support 
requirements  -  support  required  from  system  resources  to  complete  the  task.  An  example 
of  a  UCI  task  analysis  form  is  presented  as  Figure  3.  Table  2  contains  descriptions  and 
examples  of  the  type  of  data  to  be  entered  in  using  this  form. 

c)  Products.  The  products  of  this  step  are:  lessons  learned  which  will  influence  the  design  of 
UCI,  analysis  and  allocation  of  functions  to  user  or  automated  performance  or  to  interaction 
between  the  user  and  the  computer,  user  requirements,  and  user  tasks,  task  sequences  and  task 
requirements. 
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TABLE  1.  Description  of  data  fields  and  eniries  in  using  UCI  functions  analysis  form. 


Mission/UCI 
Session  Phase 


Function 


Condition 


Subfunctions 


Sequential 

operations 


Functional 

Dependencies 


Frequency 


Mission 

Criticality 


Allocation 


Gross  User 
Task' 


Identifies  the  major  level  phase  or  UCI  sequence  for  which  the 
remainder  of  the  functions  analysis  data  is  approoriate.  Examples 
inc'ude;  log-on,  air-search  (in  an  anti-air  system),  data  form 
entry  (in  a  data  base  management  system),  etc. 

Identifies  the  system  function  which  will  be  analyzed.  Examples 
include;  initialize  system,  control  air  search/radar  sweep  area, 
data  entry  and  storage,  etc. 

Specifies  the  operational  conditions  under  which  the  function  will 
be  analyzed.  Examples  include;  deoraded  radar  penetration  due  to 
environmental  conditions,  wartime  ops,  peaceti.me  ops,  etc. 

Identifies  subfunctions  which  are  subservient  to  the  high  level 
function  being  analyzed.  Examples  include;  user  authentication  at 
time  of  log-on,  control/selection  of  data  formats,  monitoring, 
pacing  and  control  of  data  input,  etc. 

List  of  sequential  human  and  computer  operations  in  the  conduct  of 
functions  and  subfunctions.  Examples  include  (for  a  log-on 
procedure):  power  terminals,  select  and  load  software,  access 
data,  authenticate  user  access,  and  so  on. 

List  of  operations  and  functions  which  are  functionally  dependent. 
For  example,  data  access  may  be  dependent  upon  authentication  of 
users,  while  saving  or  resaving  a  file  may  not  be  dependent  upon 
intervening  data  changes  or  updates. 

Estimation  of  the  frequency  of  subfunctions  and  operations  within 
the  accomplishment  of  a  high  level  function.  For  example,  user 
authentication  may  occur  once  per  session  (or  more  frequently  for 
highly  sensitive  coerations),  file  updates  every  5  minutes,  etc. 

Estimation  of  the  criticality  of  subfunctions  or  operations  success 
or  failure  upon  the  overall  accomplishment  of  the  high  level  function, 
or  overall  system  mission.  At  this  time  criticality  is  simply  assessed 
as  high,  medium,  or  low. 

A  preliminary  statement  of  function  allocation.  For  example,  user 
authentication  will  be  allocated  to  both  the  human  (expression  of 
password,  etc  )  and  the  machine  (granting  access  based  on 
password  entry),  specificatior  of  files  to  be  manipulated  would  be 
allocated  to  the  user,  etc. 

A  preliminary  list  of  high  level  user  tasks  in  accomplishing 
subfunctions  and  operations.  Examples  include;  select  file  to  be 
manipulated  (from  menu,  paper  procedures,  etc),  enter  password, 
input  required  radar  sweep  area  and  speed,  etc. 
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TABLE  2,  Description  of  data  fields  and  entries  in  using  UGI  task  analysis  form 


Mission/UCI 
Session  Phase 

Identifies  the  major  level  phase  or  UCI  sequence  for  which  the 
remainder  of  the  functions  analysis  data  is  appropriate.  This  restates 
data  from  the  functions  analysis  form. 

Function 

Identifies  the  system  function  which  will  be  analyzed.  This  restates 
data  from  the  functions  analysis  form. 

Tack 

Specifies  the  operational  task  which  will  be  analyzed,  as  indicated  on 
the  functions  analysis  form. 

Mode 

Specifies  any  modes  of  operation  under  which  the  task  may  be 
performed  or  is  appropriate.  For  example;  display  mode,  data  input 
mode,  semi-automatic  mode,  etc. 

User  Info 
Required 

Information  required  by  the  user  to  conduct  the  task,  or  to  direct  the 
system.  For  example;  password,  file  name,  data  types,  etc. 

Mediation/ 
Decision  Rules 

Information  and  rules  applied  to  decision  making  in  the  conduct  of 
decision  tasks.  For  example,  data  accuiacy  requirements,  decision 
authority,  warfare  doctrine,  etc. 

System  Info 
Required 

User  required  information  regarding  the  status  of  the  system  and 
for  its  use.  For  example:  operating  system  in  use,  equipment 
availability  (such  as  printers,  sensors  and  the  like),  etc. 

Automated 

Support 

Task  elements  which  may  be,  or  must  be,  supported  by  machine 
processing.  For  example;  on  line  calculators,  data  conversion 
software,  data  extrapolation/interpolation  support,  and  so  on. 

Control/ 

Input 

Requirements  for  user  control/inpuL  For  example,  processing 
interrupts,  directing  file  operations,  and  control  methods. 

Input  Type/ 

Mode 

Type  of  data  to  be  input  or  type  of  control  to  be  executed.  For  example: 
discrete  vs  continuous  data  input  or  control. 

System 

Response  Time 

Estimation  of  allowable  system  response  time  to  user  control/input 
actions,  basi.  j  on  system  performance  requirements.  For  example, 
time  to  solve  weapons  direction  problems  in  a  tactical  weapon  system. 

Feedback/ 

Display 

Feedback  required  for  operator  actions  and  commands.  For  example, 
status  of  machine  processing  (messages,  graphics,  etc.)  or  problems 
encountered  by  the  system  in  command  execution. 

Potential 

Errors  - 
Impacts 

Prediction  of  likely  and  plausible  errors  and  their  impact  on  mission/ 
task/function  completion.  For  example;  failure  to  remember 
password,  selection  of  incorrect  control  options,  etc.  Error  likelihood 
might  be  expressed  as  high,  medium,  and  low.  Impacts  would  be  literal 
statements  such  as  "delay  in  data  access." 
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4.1 .2.1 .3  UCI  design  task  3  -  prepare  UCI  functional  specification. 

a)  Objective.  To  produce  a  functional  specification  of  the  UCI  to  be  designed  in  phase  II.  The 
objective  of  the  UCI  functional  specification  will  be  to  guide  the  process  of  developing  design 
concepts  and  criteria  for  UCI. 

b)  Approach.  The  functional  specification  will  be  developed  in  three  basic  steps.  The  first 
step  involves  the  identification  of  UCI  design  requirements  by  user  task.  In  the  second  step  the 
requirements  will  be  integrated  and  collapsed  under  UCI  elements.  Requirements  generated  from 
user  tasks  will  be  allocated  to  specific  UCI  design  categories,  such  as:  displays,  input  devices, 
user-interface  language,  procedures  and  documentation,  and  provisions  for  training  or  help 
functions.  Finally,  these  requirements  will  be  packaged  into  a  UCI  functional  specification. 

The  functional  specification  should  address  the  capabilities  which  the  UCI  must  possess  and  the 
requirements  which  the  UCI  design  concept  must  satisfy.  It  should  address  what  the  UCI  must  do, 
and  what  it  must  be  capable  of  doing. 

The  specification  should:  1)be  readily  understood,  2)  be  precise  in  describing  the  behavior  of 
the  system  for  each  input,  3)  be  easy  to  check  for  consistency,  4)  express  system  behavior  with  a 
minimum  of  complexity,  5)  describe  the  behavior  of  a  UCI  without  constraining  the  manner  in 
which  it  will  be  implemented,  and  6),  be  closely  related  to  the  users  mental  model  of  the  system. 

The  UCI  functional  specification  should  provide  inputs  to  the  system  segment  specification,  the 
operational  concept  document  and  the  preliminary  interface  requirements  specification,  all  of 
which  are  developed  in  the  Systems  Requirements  Analysis  Phase  of  the  software  development 
process.  The  specification  should  also  support  a  description  of  the  UCI  requirements  to  be 
presented  at  the  System  Requirements  Review  and  the  System  Design  Review. 

c)  Product.  The  UCI  functional  specification. 

4.1 .2.2  phase  II  -  UCI  design  and  development.  The  objective  of  Phase  II  is  to  produce  a  UCI  Design 
Specification  document  containing  performance  criteria  for  the  recommended  user-computer 
interface.  The  functional  specification  resulting  from  Phase  I  will  serve  as  the  initial  source  of 
input  to  the  UCI  design  effort.  Based  on  the  user  requirements,  functional  allocations  and  UCI 
lessons  learned  contained  in  the  functional  specification  and  software  constraints  derived  from  the 
soliware  development  activity,  a  number  of  alternative  UCI  design  approaches  will  be  defined. 

These  approaches  include  concepts  for  overall  UCI  design,  as  well  as  concepts  for  design  of  specific 
UCI  elements. 

The  conceptualization  process  will  be  supported  by  the  implementation  of  UCI  design  studies 
such  as  rapid  prototyping  approaches  to  defining  and  refining  UCI  design  concepts.  Results  of  these 
studies  will  input  to  the  development  of  tradeoff  criteria,  and  will  include  software  constraints, 
system,  task  and  user  requirements,  and  of  lessons  learned  analyses.  Candidate  concepts  will  be 
compared  by  means  of  tradeoffs  and  a  UCI  concept  will  be  selected.  Additional  studies  will  be 
conducted  to  derive  design  criteria  for  the  selected  concept.  Finally,  the  definition  and  description 
of  the  selected  concept  and  associated  design  criteria  will  comprise  the  UCI  design  specification. 

The  products  of  this  phase  are  a  proposed  design  concept  and  design  criteria  and  a  UCI  design 
specification  which  will  be  used  to  guide  the  design  of  the  selected  concept.  The  UCI  design 
activities  will  proceed  in  parallel  with  the  preliminary  end  detailed  design  phases  of  the  software 
development  process.  The  overall  UCI  design  concept  will  be  developed  in  conjunction  with  the 
preliminary  design  phase,  and  will  be  available  for  assessment  at  the  preliminary  design  review. 

The  design  concepts  for  UCI  elements  will  be  developed  in  conjunction  with  the  detailed  design 
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phase  and  will  be  assessed  in  the  critical  design  review. 


4.1. 2.2.1  UCI  design  task  4  develop  UCI  design  concepts. 

a)  Objective.  The  objective  of  this  step  is  to  develop  alternative  UCI  design  concepts. 

b)  Approach.  The  steps  required  in  the  development  of  UCI  design  concepts  are  as  follows: 

1)  Develop  screen  display  concepts:  Requirements  driving  the  design  of  displays,  in 
terms  of  the  overall  design  concepts  as  well  as  concepts  for  display  elements,  will  be 
established.  Concepts  for  display  organization,  coding,  layout  and  format,  and 
inter-screen  relationships,  will  be  developed  for  specific  user  tasks  and  task  sequences, 
driven  by  task  requirements.  Concepts  for  overall  display  approaches  and  display 
elements  will  be  developed  in  an  iterative  manner  beginning  with  paper  simulation,  which 
defines  the  UCI  requirements  associated  with  each  user  task.  Concepts  for  display 
elements  will  be  developed  by  means  of  display  drawings  included  into  the  task  sequences 
of  the  paper  simulations.  Concepts  will  be  refined  and  completed  by  rapid  prototyping 
simulation,  described  in  the  design  development  simulation  step  of  task  5. 

2)  Develop  interaction/irar:saction  concepts:  During  paper  simulations,  requirements 
will  also  oe  developed  for  dialogs  between  the  user  and  the  software.  Interactions  will  be 
defined  as  specific  exchanges  of  informalion,  command,  or  support  between  user  and 
computer  associated  with  the  conduct  of  each  user  task.  Transactions  include  the  specific 
data  input,  display,  manipulation,  dissemination,  processing,  retrieval  or  storage 
activities  associated  with  each  interaction.  Concepts  for  interactions  will  be  developed 
primarily  in  the  preliminary  design  stage  of  software  development.  Concepts  for 
transactions  will  be  developed  in  the  detailed  design  phase. 

3)  Develop  concepts  for  procedures  and  decision  aids:  The  paper  simulations,  when 
completed,  will  serve  as  the  basis  for  defining  concepts  for  user  procedures  and  decision 
aids. 

c)  Product.  Products  of  this  task  are  UCI  desian  concepts. 

4.1 .2.2.2  UCI  design  task  5  -  conduct  design  studies  and  tradeoffs. 

a)  Objective.  To  perform  a  preliminary  evaluation  of  the  proposed  display  design  concept, 
and  identify  the  constraints  of  system  development  and  implementation  which  serve  as  boundaries 
around  the  various  design  solutions, 

b)  Approach.  An  iterative  approach  to  dersign  concept  selection  is  proposed  based  on  the 
following  three  steps: 

1 )  Conduct  design  development  simulation.  Design  development  simulations  are  conducicd 
for  three  separate  objectives:  a)  to  support  the  development  of  UCI  design  concepts:  b)  to 
provide  user  performance  data  for  individual  design  concepts  which  serve  as  inputs 
to  tradeoffs  of  alternate  concepts;  and  c)  to  define  design  criteria  associated  with  selected 
UCI  concepts  Design  development  simulations  include  paper  simulations  described  in  task 
2.1 ,  table-top  walkthroughs  of  user  tasks  with  associated  display  drawings,  and  rapid 


1  6 


MIL-HDBK-761A 


prototype  evaluation  tools  including  provisions  for  mocking  up,  assessing  and  modifying 
displays,  protocols,  dialogs,  decision  aids,  data  input,  and  training  provisions. 

2)  Develop  tradeoff  criteria.  Criteria  for  evaluating  the  relative  merits  of  alternate  UCI 
design  concepts  will  be  developed  based  on  expected  user  capabilities  and  needs,  empirical 
data  on  representative  user  performance,  system  and  task  requirements,  lessons  learned, 
and  software  constraints. 

3)  Conduct  UCI  tradeoffs.  Alternative  UCI  design  concepts,  at  the  overall  UCI  level  and  at 
the  level  of  UCI  elements,  will  be  evaluated  on  the  tradeoff  criteria.  When  UCI  concepts 
have  been  selected,  additional  studies  will  be  conducted  to  develop  design  criteria 
associated  with  individual  design  concepts 

c)  Products.  The  product  at  the  conclusion  of  this  task  will  be  selected  UCI  design  concepts 
and  associated  design  criteria. 

4.1. 2.2.3  UCI  design  task  6  -  prepare  UCI  design  specification. 

a)  Qbiective.  To  produce  a  design  specification  that  documents  the  UCI  design  criteria. 

b)  Approach.  The  UCI  design  specification  will  address: 

1 )  Display  design.  Data  on  information  content,  organization  and  format,  user  tasks, 
inter-screen  relationships,  and  display  elements. 

2)  Input  device  design.  Data  on  data  input,  manipulation,  and  modification. 

3)  Interactive  dialog  design.  Including  interactions  between  user  and  software,  and 
specific  transactions  which  enable  the  interactions. 

4)  Decision  aid  design.  Data  on  techniques  to  support  the  decision-making  process  of  the 
user,  ranging  from  overlays  to  artificiai  intelligence. 

5)  Procedures  design  criteria.  Data  on  sequences,  subroutines,  task  dependencies, 
procedural  constraints,  and  user  documentation. 

6)  Training  design  criteria.  Data  on  tutorials,  help  functions  and  instruction. 

7)  Maintenance  criteria.  Data  on  procedures  required  to  maintain,  repair,  and  update  the 
UCI  system. 

c)  Product.  A  UCI  design  specification  containing  criteria  for  UCI  design  and  development. 

4.1 .2.3  phase  III:  UCI  test  and  integration.  The  objective  of  this  phase  is  to  formally  evaluate  the 
UCI  design  concept,  complete  the  integration  of  the  UCI  with  system  software,  and  produce  the  UCI 
implementation  specification,  which  contains  the  requirements  for  actual  implementation  of  the 

UCI  within  the  system.  During  this  Phase  the  UCI  design  will  be  tested  and  fully  integrated  with 
system  software.  Design  verification  simulations  will  be  conducted  which  are  similar  to  the  design 
development  simulations  described  in  task  2.3.  When  the  specifics  of  the  UCI  design  have  been 
verified,  user  acceptance  tests  will  be  conducted  to  ensure  that  the  UCI  approach  and  elements  meet 
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user  expectations  and  mission  needs  while  meeting  acceptance  criteria  for  complexity,  ease  of 
learning,  retention,  transparency,  directiveness,  and  user  workload.  UCI  design  approaches  will 
be  integrated  with 

system  software,  and  with  UCI  of  associated  systems.  In  addition,  requirements  for  UCI 
implementation  will  be  established  and  packaged  in  a  UCI  implementation  specification.  The  major 
products  of  this  phase  ero  the  vor'^ic:.ticn  wniidetion  of  ’ho  l  ICI  design,  integration  of  the  UCI 
with  system  software,  and  UCI  implementation  criteria.  Activities  in  this  phase  of  UCI 
development  are  conducted  in  the  system  Test  and  integration  phases  of  software  development.  The 
UCI  implementation  specification  will  serve  as  an  input  to  the  software  test  description, 
operations  and  support  documents,  system  integration  test  procedures,  and  the  software  product 
specification. 

4.1. 2.3.1  UCI  design  (ask  7  -  conduct  design  verification. 

a)  Objective.  This  step  addresses  the  verification  of  the  selected  UCI  design  approach  prior  to 
formal  user  acceptance  testing. 

b)  Approach.  This  step  will  employ  rapid  prototyping  methodologies  to  simulate  and  evaluate 
the  effectiveness  of  the  selected  UCI  design  concept.  Requirements  associated  with  the  conduct  of 
design  verification  simulation  include  the  following:  selection  of  missions,  mission  conditions, 
functions  and  tasks  to  be  simulated;  and  the  identification  of  performance  measures.  Requirements 
also  include:  the  identification  of  standards  of  performance  or  performance  criteria  against  which 
performance  data  are  compared,  based  on  task  and  system  requirements:  identification  of 
requirements  for  data  and  for  data  acquisition  and  recording:  and  identification  of  simulation 
methods  which  includes  concerns  for  simulation  fidelity  and  experimental  control. 

c)  Products.  Results  of  design  verification  simulations. 

4.1 .2.3.2  UCI  design  task  8  -  conduct  user  acceptance  tests. 

a)  Objective.  Conduct  user  acceptance  testing  of  the  design  of  the  selected  UCI  design  concept. 

b)  Approach.  During  this  step,  the  UCI  design  concepts  verified  in  the  previous  step  are 
tested  to  ensure  that  the  interface  satisfies  the  user  defined  requirements.  The  goal  of  acceptance 
tests  is  to  force  as  much  of  the  evolutionary  development  as  possible  into  the  pre-release  phase, 
when  change  is  easy  and  relatively  inexpensive.  In  conducting  the  acceptance  tests  the  effort  will 
proceed  systematically  through  the  following  three  stages. 

1)  Individual  user  controlled  tests.  This  is  an  informal  evaluation  in  which  a 
representative  user  attempts  to  use  the  system  in  a  rapid  prototyping  mode.  During  this 
stage  there  is  interaction  with  the  UCI  designers  concerning  difficulties  encountered.  At 
the  conclusion  of  the  session,  the  user  describes  difficulties  encountered  in  attempting  to 
use  the  interface. 

2)  Small-group  evaluation.  During  this  next  stage  of  evaluation,  a  group  of  potential 
users  attempts  to  use  the  system  with  minimal  intervention  from  UCI  designers.  Errors 
and  difficulties  are  noted,  and  the  system  is  redesigned  in  an  attempt  to  remove  these 
problem  areas.  The  test  methods  include  subjective  attitude  questionnaires,  structured 
interviews,  and  objective  on-line  performance  assessments  to  isolate  problem  areas 
requiring  interfao.''  redesign. 
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3)  Fiftid  fivaliiation.  In  this  stage,  which  is  also  referred  to  as  beta  testing  or  site 
testing,  the  system  is  field  tested  to  simulate  the  actual  training  and  work  environment. 

During  this  stage  objective  user  performance  data  are  collected  to  ensure  that  software 
and  user  intedaces  are  subjected  to  a  thorough  evaluation.  This  evaluation  should  ensure 
that  the  system  is  satisfactory  for  all  missions  for  which  it  was  designed.  While  a  rapid 
prototvping  methodology  is  acceptable  to  simulate  system  opemtinnc  and  neer  tasks  in 
earlier  stages  of  user  acceptance  testing,  the  field  test  should  employ  actual  software, 
hardware  and  procedures. 

c)  Products.  Results  of  user  acceptance  tests,  and  requirements  for  UCI  design  modifications. 

4.1. 2.3.3  UCI  design  task  9  -  integrate  UCI  and  system  software. 

a)  Objective.  To  integrate  the  elements  of  the  UCI  into  system  software  to  support  user 
information  requirements,  decisions  and  transactions. 

b)  Approach.  This  step  will  begin  with  the  development  of  integration  criteria.  These 
criteria  will  address  such  issues  as;  what  integration  is  required?  How  much  integration  is 
needed?  How  should  the  integration  be  achieved?  The  integrations  of  primary  concern  include;  the 
integration  of  software  and  user  interfaces:  the  integration  of  different  software  subroutines  with 
user  procedural  subroutines:  the  integration  of  different  display  screens:  the  integration  of  user 
interface  transactions  and  mission  oriented  tasks:  and  the  integration  of  displays,  transactions, 
dialogs  and  user  procedures. 

The  integrating  activities  should  be  accomplished  iteratively  with  design  verification  tests  and 
user  acceptance  tests  to  ensure  that  the  integration  process  does  not  adversely  affect  the  usability 
of  the  graphic  interfaces. 

c)  Products.  Results  of  design  integration  efforts. 

4.1. 2.3.4  Task  10  -  develop  the  UCI  implementation  specification. 

a)  Objective.  To  define  requirements  for  UCI  implementation,  and  to  prepare  an 
implementation  specification. 

b)  Approacii.  This  step  begins  with  requirements  for  UCI  procedures,  based  on  required 
transactions  between  user  and  graphic  interfaces,  and  also  based  on  user  tasks  and  task  sequences. 

Based  on  procedures,  training  requirements  will  be  developed.  Training  requirements  are  of 
three  types;  job  requirements,  course  requirements,  and  training  system  requirements.  Job 
requirements  include  tasks  to  be  trained  and  training  objectives.  Course  requirements  include 
determination  of  the  training  course  content.  Training  system  requirements  include  determination 
of  training  methods,  media,  materials,  measures,  and  training  management  requirements. 

User  documentation  will  be  developed  based  on  procedures  and  training  requirements.  User 
documentation  includes  hardcopy  procedures,  instructions  and  advisories  as  well  as  on-line  help, 
user  prompts,  augmented  feedback  and  tutorials. 

UCI  implementation  requirements  include  requirements  for  interrelating  user  interfaces  with 
procedures,  training  and  user  documentation,  and  guidelines  for  software  developers  concerning 
design  criteria  associated  with  specific  interface  concepts.  These  guidelines  will  identify  the  extent 
to  which  an  interface  must  adhere  exactly  to  the  criteria,  and  to  what  degree  can  it  deviate  from 
the  criteria  to  facilitate  the  programming  effort. 


1  9 


MIL-HDBK-761A 


The  UCI  Implementation  specification  will  embody  the  guidelines  concerning  integration  of 
user  interfaces  with  procedures,  training  and  documentation,  and  also  the  guidelines  addressing 
the  limits  to  which  the  interface  design  criteria  must  be  strictly  enforced. 

c)  Product,  the  product  of  this  step  is  the  UCI  implementation  specification,  describing  user 
transactions,  procedures,  training,  documentation,  interrelationships  among  these  elements,  and 
guidelines  on  implementation  of  the  graphic  interfaces. 
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4.2  General  approach  to  rapid  prototvoina. 

Existing  guidelines  generally  are  not  able  to  resolve  interface  design  issues  that  are  context 
sensitive,  such  as  selecting  the  proper  dialog  technique  for  a  specific  group  of  users  performing  a 
particular  task.  In  most  interface  design  projects,  this  problem  can  be  obviated  through  the 
application  of  interface  prototypes. 

in  a  basic  form,  a  prototype  can  be  a  simple  screen  image  or  a  drawing  of  a  single  display 
screen,  showing  the  location,  coding,  information  characteristics,  etc.,  of  interface  elements. 

More  sophisticated  prototypes  emulate  more  o'  the  dynamic  characteristics  of  the  user  interface, 
and  are  usually  displayed  on  a  graphics  terminal.  The  prototyping  process  is  evolutionary,  and 
therefore,  prototypers  should  provide  rapid  prototype  development  which  will  change  with  use  in 
designing,  developing,  and  evaluating  the  interfaces  emulated. 

4.2.1  Levels  of  DrototvDing. 

The  prototypes  presented  here  are  considered  in  three  levels,  corresponding  to  levels  of 
sophistication  in  emulating  the  UCI  under  development: 

a)  Static  prototypes.  These  allow  evaluation  of  sets  of  displays  pages,  formats  for  data, 
arrangements,  coding,  etc.  in  a  static  mode.  The  media  for  presentation  of  static  prototypes 
may  be  static  displays  on  a  VDT,  or  paper  images  presenting  display  windows,  colors, 
representative  sizes,  etc.  Paper  versions  may  be  included  in  surveys  for  purposes  of  review 
and  annotation.  Static  prototypes  are  primarily  used  for  the  identification  and  resolution  of 
design  issues,  and  for  the  conduct  of  design  tradeoffs.  Tradeoffs  conducted  may  address  the 
fundamental  nature  of  the  interface,  for  example  use  of  menu  vs  command  driven  dialog. 

b)  Dynamic  prototypes.  These  allow  evaluation  of  a  rough  model  of  the  system  on  a  graphics 
workstation  or  terminal.  A  subset  of  the  dynamic  characteristics  of  the  developing  interface 
should  be  provided  by  this  prototype.  Dynamic  characteristics  should  include,  paging  among 
displays,  presentation  of  menus,  help  screens,  prompts,  limited  data  input  and  editing,  and  so 
forth.  Other  dynamic  characteristics  should  be  simulated  for  design  elements  which  may  be 
critical  to  human  performance  and  which  may  be  resolved  through  dynamic  prototyping. 
Dynamic  prototypes  should  be  used  to:  conduct  design  tradeoffs  at  a  more  detailed  level  (e.g., 
level  of  menu  hierarchy  depth  vs.  breadth)  than  static  prototypes;  to  generate  detailed  design 
concepts;  and  to  validate  design  in  terms  of  meeting  performance  requirements. 

c)  Robust  prototypes.  These  should  be  relatively  complete  in  terms  of  accurately  simulating 
the  dynamic  characteristics  of  an  interface.  Robust  prototypes  should  provide  near  perfect 
fidelity  with  the  actual  system  interface,  including  simulation  of  characteristics  such  as 
presentation  of  error  messages,  system  response  times,  display  code  status  changes,  data 
entry,  editing  and  recall,  etc.  Robust  prototypes  should  generally  be  used  to  validate  design 
and  accomplishment  of  design  objectives,  and  may  be  used  to  perform  design  tradeoffs  at  a 
detailed  level  (for  example,  comparing  different  sequences  for  advancing  among  data  fields 
with  a  form). 
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As  the  general  case,  the  level  of  sophistication  of  the  prototype  should  advance  through  the 
user-computer  interface  design  process.  During  the  early  stages  of  interface  design  development, 
static  prototypes  will  likely  be  used  to  evaluate  general  UCI  concepts  for  areas  such  as  information 
density,  display  arrangements,  dialog  mode,  help  displays  and  the  like.  As  the  design  concepts 
become  increasingly  more  detailed,  dynamic,  then  robust  prototypes  should  be  used  to  further 
evaluate  interface  concepts  in  a  more  behavioral,  interactive  context.  The  steps  in  the  human 
engineering  software  development  cycle,  such  as  user  needs  analysis  and  task  analysis,  that  take 
place  prior  to,  and  concurrent  with,  the  prototype  process  are  crucial  to  prototyping.  The 
information  and  data  gathered  during  the  task  analysis  and  the  specification  of  the  user 
requirements  contribute  key  data  throughout  the  prototype  process.  Utilizing  prototyping 
technology  must  be  in  conjunction  with  the  full  user-computer  interface  development  cycle.  The 
discussion  presented  in  this  section  assumes  that  most,  if  not  all,  of  the  Phase  I  activities  presented 
in  section  4.1  are  complete,  that  general  UCI  concept  formation  has  begun  in  accordance  with  Phase 
II,  and  that  the  capabilities  and  limitations  of  the  end  system  hardware  are  used  in  constraining  the 
capabilities  of  the  rapid  prototyping  system  to  be  used. 

4.2.2  Human  engineering  techniques  and  methods  used  with  prototypes. 

Techniques  available  for  gathering  user  data  vary  with  respect  to  accuracy  and  utility  of  the 
data  collected,  the  amount  of  time  to  apply  the  technique,  and  the  number  and  skill  level  of  users 
that  must  participate.  In  addition,  certain  techniques  will  be  more  appropriate  at  specific  phases 
of  prototype  development.  In  all  cases,  the  objective  in  applying  the  techniques  is  to  evaluate  and 
refine  the  user-computer  interface  in  terms  of  meeting  the  needs  of  the  user  and  accomplishing  the 
system  mission.  Methods  and  techniques  to  extract  user  data  using  prototyping  tools  include; 
DOD-HDBK-763  Human  Engineering  Procedures  Guide,  direct  observation,  performance  of  pilot 
studies,  human  subject  experimentation,  user  interviews,  and  automated  data  collection  during  a 
prototyped  user-computer  interface  session.  Each  of  these  is  briefly  introduced  below. 

4.2.2. 1  User  data  and  interviews. 

As  a  general  case,  UCI  development  represents  an  evolution  of  previous  MIS/UCI  systems  (for 
example,  the  evolution  of  sensor  systems  and  combat  directions  systems  with  associated  tactical 
displays,  situations  displays,  and  the  like).  User  data  may  be  collected  even  though  the  details  of 
the  interface  to  be  designed  are  not  yet  known  or  specified.  In  this  sense,  user  data  should  be 
collected  using  precedent  systems  users,  soliciting  their  experiences  and  insights,  and  observing 
interface  behaviors  using  either  or  both  the  precedent  systems  or  prototyped  conceptual  interfaces 
of  the  systems  under  development. 

User  data  and  information  which  will  support  the  rapid  prototype  process,  and  should  be 
identified,  includes:  1),  existing  systems  and  task  experience  such  as  terminology;  spatial  and 
movement  compatibility;  knowledge  structures;  natural  task  solutions;  statistics;  evaluation  of 
existing  (competitive)  systems;  performance  on  existing  systems;  ratings  of  task  difficulty;  job 
aids,  and  2),  planned  system  considerations  such  as  ratings  of  icons,  graphics  and  text  formats; 
data  input,  editing  and  control  requirements;  performance  times  and  errors:  dialog  and  command 
modes;  data  forms  and  formats/arrangements;  job  aiding;  error  diagnosis,  etc. 

During  interviews,  discussions  are  held  with  the  intended  users  of  the  interface  to  clarify  the 
users  needs  for  this  system.  This  process  takes  place  after  the  Phase  I  activities,  and  requires  task 
descriptions,  functional  specifications,  estimated  task  performance  time  and  frequency  data,  error 
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information,  task  difficulty  information,  and  the  skills  and  knowledge  required  to  perform  the 
tasks.  Interviews  should  involve  gathering  information  to  help  the  designer  and  the  user  translate 
task  analysis  and  functional  requirement  specifications  into  user  interface  needs.  Interview 
techniques  which  can  be  used  at  this  stage  including  individual  interviews,  group  discussions, 
questionnaires,  rating  forms,  free-recall  techniques,  and  sorting  techniques.  These  techniques  can 
be  used  with  any  of  the  prototypes  presented  above. 

4. 2. 2. 2  Direct  observation. 

Direct  observation  entails  viewing  of  users  during  task  performance  using  an  actual  or 
prototyped  system.  Videotaping  task  performance  is  included  in  this  category.  Direct  observation 
should  be  used  to  gather  a  range  of  descriptive  data  about  the  user-system  interaction,  to  perform 
activity  sampling  of  task  frequency  and  duration,  and  to  identify  problems  with  existing  interfaces. 

This  form  of  data  gathering  requires  that  the  users  be  present  at  the  site  of  the  prototype  or 
system  being  evaluated.  It  also  requires  a  fair  amount  of  time  on  the  part  of  the  users  as  well  as  the 
designers.  One  of  its  main  advantages  is  that  direct  observation  is  likely  to  yield  findings  which 
may  not  be  easily  obtained  by  other  methods.  In  many  situations  it  is  advisable  to  observe 
user-system  interaction  while  the  user  narrates/annotates  the  session.  Data  to  be  identified  during 
these  "talking  sessions"  include  normally  not  observable  behaviors  such  as  user  goals/intentions, 
visual  references,  cognitive  approaches  to  the  interaction,  problem  solving  strategies  being 
employed,  user  expectations  regarding  system  processing  and  response,  timing  and  phasing  of 
transactions  (as  in  a  users  stating  a  waiting  interval  for  an  expected  system  response,  or  user 
cognitive  process  in  generating  a  transaction  approach,  etc),  and  user  uncertainties  and  their 
approaches  to  reduce  uncertainty.  Direct  observation  generally  should  be  used  with  dynamic  and 
robust  prototypes. 

4. 2. 2.3  Pilot  studies  and  experiments. 

Pilot  studies  should  be  used  to  evaluate  attributes  of  stimulus  materials  that  will  be  used  in  an 
experiment,  to  compare  design  alternatives,  and  to  conduct  informal  studies  were  there  is  no 
formal  hypothesis  testing,  well  defined  variables,  or  statistical  testing  of  data.  Descriptive 
statistics,  however,  should  be  generated,  such  as  mean  response  times  of  both  the  equipment  and  the 
user,  mean  throughput  time,  and  minimum  and  maximum  throughput  time.  Any  errors  which 
occur  during  pilot  studies  should  be  noted.  There  are  a  range  of  procedures  normally  utilized 
during  experiments  that  can  be  run  as  a  pilot  study.  These  procedures  include  free-recall  tasks, 
sorting  tasks,  rating  tasks,  as  well  as  measurable  performance  tasks 

An  experiment  should  be  designed  and  conducted  where  it  is  required  to  test  a  hypothesis  or 
hypotheses,  when  there  are  critical  interface  choices  with  clearly  defined  variables,  and  when  the 
design  team  needs  to  compare  the  performance  on  alternative  interfaces  for  given  task/mission 
critical  sequences  that  have  not  been  adequately  analyzed.  The  data  collected  from  an  experiment 
should  be  analyzed  with  parametric  statistics,  should  conform  to  the  principles  of  experimental 
design,  and  should  lead  to  specific  decisions  regarding  UCI  design. 

Pilot  studies  and  experiments  should  generally  be  used  with  dynamic  or  robust  prototypes. 

4.2.2.4  Surveys. 

Surveys  provide  a  way  to  obtain  user  preferences,  ratings,  opinions,  or  data  on  an  interface. 
Surveys  can  be  conducted  in  a  number  of  different  modes  including  on-line,  written,  face  to  face 
interviews,  and  group  discussions.  The  survey  has  the  advantage  that  it  can  be  anonymous  and 
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therefore  may  elicit  more  subjectively  true  opinions  and  ratings.  With  a  large  sample,  survey  data 
can  be  analyzed  statistically.  Surveys  can  be  used  to  gathei  user  ratings  on  some  important 
dimensions  of  interface  design.  Surveys  can  be  designed  to  have  users  rate  their  preferences,  and 
requirements  for  the  new  interface.  Surveys  can  also  be  used  to  have  users  rate  prototypes  as  well 
as  existing  systems.  When  a  written  survey  is  being  conducted,  a  relatively  la  ge  sample  of  the 
user  population  can  be  surveyed  inexpensively.  These  written  surveys  do  not  have  to  take  up  muou 
of  the  users  time,  so  they  can  be  an  efficient  way  of  gathering  data.  Surveys  may  used  with  static, 
dynamic  or  robust  prototypes. 

4.2.2.5  Continuous  data  collection. 

Automatic  collection  of  user  data  can  be  accomplished  on  prototype  systems,  existing  systems, 
and  completed  versions  of  the  new  system.  A  range  of  user  data  can  be  collected,  including  error 
rate  data,  frequency  and  length  of  on-line  help  requests,  number  of  system  error  messages,  and 
throughput  and  time-on-task  data. 

The  advantage  of  this  technique  is  that  it  is  nonintrusive.  One  limitation  is  that  software  is 
required  to  run  in  the  background,  thus  limiting  application  of  this  technique  to  the  rapid  or  robust 
prototype  as  well  as  the  finished  system.  This  technique  normally  gathers  large  amounts  of  data  so 
that  the  design  team  may  gave  the  problem  of  performing  data  reduction  prior  to  the  analysis. 

Continuous  data  collection  should  only  be  used  with  robust  prototypes,  unless  performance 
measures  are  selected  which  are  appropriate  for  the  specific  limitations  of  a  lower  fidelity 
prototype  (for  example,  some  error  data  may  be  appropriate,  but  timed  measures  probably  will 
not  be  appropriate  with  something  less  than  a  robust  prototype). 

4.2.3  Use  of  prototypes. 

4.2.3.1  Use  of  static  prototypes. 

Static  prototypes  should  be  used  for  evaluation  of  UCI  interface  which  are  stable  in  display 
presentation,  and  are  not  specifically  related  to  time  dependent  operations  (such  as  data  searches, 
peripheral  device  operations,  etc.),  transitional  transactions  (such  as  mode  changes),  or  data 
exchange/handling  operations  (such  data  input  or  editing,  printing,  audible  displays,  alerts,  etc). 

UCI  design  considerations  which  sfiould  be  addressed  using  static  prototypes  include: 

a)  display  layouts  and  arrangements 

b)  displayed  data  content  (comprehensiveness,  information  density,  accuracy) 

c)  dialog  format  selection  (menu  structures,  commands,  query  formation,  etc) 

d)  job  performance  aid/help  screen  design  and  content 

e)  display  arrangement  standards  and  consistency 

f)  information  coding  (use  of  colors,  symbols,  and  other  static  codes) 

g)  terms,  abbreviations,  acronyms  and  labels 

h)  error  and  prompt  message  design. 

4  2.3.2  Use  of  dynamic  rapid  prototypes. 

Dynamic  prototypes  should  be  used  for  evaluation  of  UCI  interface  which  are  stable  in  display 
presentation,  and  for  evaluation  of  the  dynamic  characteristics  which  are  simulated  by  the 
prototype.  In  general,  dynamic  prototypes  should  simulate  operations  such  as  paging  through 
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displays,  navigating  though  menu  hierarchies,  limited  data  entry  and  access,  and  requesting  and 
receiving  system  help.  Dynamic  prototypes  should  not  be  used  (unless  specifically  accommodated 
by  the  prototype)  to  evaluate  time  dependent  operations,  transitional  transactions,  or  data 
exchange/handling  operations.  UCI  design  considerations  which  should  be  addressed  using  dynamic 
prototypes  include,  in  addition  the  the  considerations  of  static  prototypes. 

a)  menu  hierarchic  design,  structure  and  organization 

b)  data  entry  and  simple  data  access  (display  paging,  scrolling) 

c)  command  structure  (tradeoffs  of  iconic/command/key  functions,  etc) 

d)  help  access 

e)  command  sequences,  display  sequences 

f)  display  formats  and  consistency. 

4.2.3.5  Use  of  robust  prototypes. 

Robust  prototypes  should  be  used  for  evaluation  of  the  dynamic  characteristic  of  UCI  interfaces. 
Robust  prototypes  should  simulate  most,  if  not  all,  user-computer  interactions.  Where  possible, 
robust  prototypes  should  incorporate  the  underlying  applications  code  which  will  manipulate  data 
in  the  final  system,  or  should  simulate  actual  data  handling.  The  timing  and  pacing  characteristics 
of  the  robust  prototype  should  closely  approximate  that  of  the  final  system.  UCI  design 
considerations  which  should  be  addressed  using  robust  prototypes  include: 

a)  control  operations  (menus,  commands,  function  keys,  queries,  merging 
commands,  etc.) 

b)  data  entry,  editing  and  access 

c)  system  prompting,  cueing,  structuring 

d)  error  detection,  errors  messages  and  user  responses 

e)  graphics,  data  manipulation 

f)  display  dynamics  (symbol  movement  such  as  velocity  vectors,  text  updates 
other  than  that  of  the  user,  cursor  flashing,  etc) 

g)  data  field  entry  (cursor  movement,  tabbing,  etc) 

h)  dynamic  coding  (flash  rates,  intensity,  auditory  signals,  colors,  speech,  etc) 

i)  device  inputs/outputs 

j)  panning,  paging,  zooming,  scrolling,  searching,  etc. 
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4.3  General  HFE  principles  of  UCI  design.  User-computer  interfaces  should  be  designed  in 
conformance  with  tne  following  nine  general  human  factors  engineering  principles  of 
user-computer  interface  design: 

4.3.1  Acceptable  workload  -  Workload  should  be  within  the  capability  limits  of  the  user,  and 
where  possible,  the  user  should  direct  system  operation  and  control  the  pace  of  transacting  with  the 
system. 

4.3.2  Assurabilitv  -  The  system  should  help  assure  data  quality  and  transaction  control  by 
supporting  the  user  in  validating  data,  avoiding  input  errors,  notifying  the  user  of  detected  errors, 
and  offering  guidance  in  correcting  enors. 

4.3.3  Brevity-  User  input  and  computer  output  should  be  brief  and  sonc'se  and  should  reduce 
long  at  d  short  term  memory  loads  imposed  on  the  user,  and  where  possible,  recognition  rather  than 
recall  should  be  required  of  the  user. 

4.3.4  Compatibility  -  User  input  should  be  compatible  with  computer  output,  and  computer 
output  should  be  compatible  with  human  expectations,  information  assimilation  capabilities,  and 
information  processing  capabilities. 

4.3.5  Consistency  -  The  system  should  provide  a  consistent  interface  environment  and  perform 
in  a  consistent,  reliable,  and  predictable  fashion. 

4.3.6  Definition  of  role  -  The  user  should  know  what  functions  the  user  will  perform  and  what 
functions  the  system  will  perform  within  dialogs. 

4.3.7  Flexibilitv/adaptabilitv  -  User  input  and  computer  output  should  depend  on  user 
experience,  capability,  expectai'on,  and  individual  style,  and  should  accommodate  individual 
differences  in  style  and  abilities. 

4.3.8  Feedback  -  Immediate  feedback  should  be  provided  the  user  concerning  system  status  and 
user  performance. 

4.3.9  Simplicity  -  User  input  and  computer  output  should  be  formed  into  short,  readily 
understandable  structures. 
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5  Dfitailed  guidelines. 

5.1  Dialoa/interactive  control. 

5.1.1  General. 

a)  The  user  should  have  the  initiative  in  transaction  control,  and  system  control  should  be 
subordinate  to  user  control.  Users  should  provide  the  pace  of  transaction  sequencf><;. 

b)  Transaction  control  should  be  by  explicit  user  action. 

c)  Control  by  simultaneous  users  should  not  interfere  with  those  of  other  users. 

d)  Transaction  options  should  be  provided  which  match  expected  user  goals  and  tasks.  For 
example,  if  users  must  frequently  sort  data  by  selected  data  elements  within  a  form,  a  simple  to 
implement  SORT  BY  command  should  be  provided. 

5. 1.1.1  Log-on. 

a)  When  users  must  log-on  to  a  system,  log-on  should  be  a  separate  procedure  that  is 
completed  before  a  user  may  select  any  operational  options. 

b)  The  log-on  frame  should  appear  as  soon  as  possible  on  the  display  with  no  additional  user 
involvement  and  should  include  prompts  for  the  log-on  procedure. 

c)  Log-on  delays  should  be  accompanied  by  an  advisory  message  to  tell  the  user  status  and 
when  the  system  will  become  available.  See  figure  4. 


**  Notice  ** 


System  unavailable  until 
1400  hours 


FIGURE  4.  Example  log-on  frame  notice. 


d)  Knowledge  of  the  internal  mechanisms  and  other  technical  aspects  of  the  system  should 
not  be  required  of  the  user  to  log-on  or  otherwise  use  the  system. 

e)  Average  system  response  time,  if  affected  by  the  number  of  on-line  users,  should  be 
displayed  at  time  of  log-on.  This  message  should  not  be  in  code  but  should  contain  specific 
information  concerning  current  response  time  and  the  periods  when  response  time  is  relatively 
quick.  Examples  of  system  response  time  messages  are  contained  in  figure  5. 

f)  After  completing  the  log-on  process,  the  user  should  be  able  to  start  productive  work 
immediately. 
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Dialog/interactive  control  -  General 


Koor 

Better 

System  load  4 

System  load  medium 

Current  maximum  response  to  simple  commands 
is  now  running  at  10  to  15  seconds. 

System  response  time  is  usually  1  to  2  seconds 
between  1100  and  1200  and  after  1600  hours. 

FIGURE  5.  Examples  of  loa-on  response  time  messages 


5.1. 1.2  Log  off. 

a)  If  there  are  pending  actions  and  the  user  requests  a  log-off,  the  system  should  inform  the 
user  that  these  actions  will  be  lost. 

b)  Interactive  timesharing  systems  should  allow  time  (e.g.,  5  to  15  minutes),  between 
keyboard  actions  before  automatic  log-off,  unless  a  longer  period  is  requested  by  the  user. 

c)  An  audible  signal  should  be  presented  at  specified  intervals  prior  to  automatic  log-off. 

d)  Where  possible,  open  files  should  be  saved  to  some  defined  file  name.  An  example  of  an 
automatic  file  save  dialog  is  presented  in  figure  6. 

e)  A  message  should  be  presented  on  screen  prior  to  the  automatic  log-off  instructing  the 
user  how  to  avoid  automatic  log-off. 


**  NOTICE  ** 

Session  log-off  due  to  user  inactivity. 


File  saved  to  user  account  as: 


Malone. ScratchFile. 6:6:88" 


FIGURE  6.  Automatic  file  closure  and  saving  operation  at  time  of  loa-off. 


5. 1.1.3  Simplicity. 

a)  Transaction  control  should  be  simple,  flexible,  adaptive,  consistent,  minimize  user 
actions,  compatible  with  the  lowest  anticipated  user  skill  level,  and  should  be  logical  in  terms  of 
user  task  sequences  and  functions. 

b)  Users  should  be  able  to  predict  system  responses  to  their  actions. 
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Dialog/interactive  control  -  General 


c)  Transaction  control  should  be  consistent  in  form  and  consequences  and  employ  similar 
means  to  accomplish  similar  ends. 

d)  When  hierarchical  levels  are  used  to  control  a  process  or  sequence,  the  number  of  levels 
should  be  minimized. 

e)  Display  and  input  formats  should  be  similar  within  levels  and  the  system  should  indicate 
current  positions  within  a  sequence. 

5. 1.1.4  Transaction  selection. 

5.1 .1 .4.1  Timing  and  pacing.  Users  should  be  able  to  select  transactions;  computer  processing 
constraints  should  not  dictate  transaction  control.  When  appropriate  to  task  requirements,  users 
should  be  able  to  specify  transaction  timing;  i.e.,  when  a  requested  transaction  should  start  or  be 
completed,  or  the  periodic  scheduling  of  repeated  transactions.  See  figure  7. 


Set  automatic  Transmission  for  every 


5 


Minutes? 

<ENTER>  to  accept  default,  or, 
input  new  value  then  <ENTER>  to  change. 


FIGURE  7.  User  specification  of  optimal  transaction  timing 


5. 1.1. 4.2  Options  list/prompting. 

a)  A  general  list  of  basic  control  options  should  be  available  to  serve  as  a  "home  base"  or 
consistent  starting  point  for  control  entries. 

b)  A  general  options  list  should  present  options  grouped,  labeled  and  ordered  in  terms  of 
their  logical  function,  sequence,  frequency,  and  aiticality  of  use. 

c)  A  list  of  the  control  options  that  are  specifically  appropriate  for  any  transaction  should 
be  displayed  by  listing  in  the  working  display  or  by  user  command. 

d)  Information  that  the  user  needs  to  perform  transactions  should  be  displayed  without 
burdening  short  and  long  term  memory. 

e)  Transactions  should  never  leave  the  user  without  further  available  action  and  should 
provide  next  steps  or  alternatives,  for  example,  "Continue",  "Abort",  "Go  to  Main  directory",  etc. 

f)  Control  entry  prompting  (e.g.,  HELP  functions)  should  be  provided. 
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Dialog/interactive  control  -  General 


5.1. 1.4.3  Command  selection. 

a)  Task  oriented  wording  for  control  options  should  be  used  to  reflect  the  users  view  of  the 
current  transaction;  for  example,  when  assigning  aircraft  to  a  mission,  the  relevant  control  option 
should  be  ASSIGN  rather  than  ENTER. 

b)  Only  available  transaction  options  should  be  offered  to  users  and  control  defaults  should 
be  indicated. 

c)  A  consistent  control  option  to  continue  to  the  next  transaction  should  be  provided;  e.g.,  if 
data  entry  is  involved,  then  user  should  be  required  to  take  an  explicit  ENTER  action  to  signal  data 
entry,  rather  than  simply  selecting  CONTINUE,  ENTER,  TAB  or  NEXT. 

d)  User  interrupt  or  abort  functions  to  terminate  transactions  should  be  provided. 

e)  The  requirement  to  learn  mnemonics,  codes,  special  or  long  sequences,  and  special 
instructions  should  be  minimized.  See  example  in  figure  8. 


POOR 

BETTER 

ATTN;., ©PRINT 

PRINTER  1/PRINT 

FIGURES.  Examples  of  poor  and  better  command  selection 


5. 1.1. 4.4  Merging  commands. 

a)  Users  should  be  able  to  key  a  sequence  of  commands  or  option  codes  as  a  single  control 
entry,  and  should  be  able  to  assign  a  name  and  use  that  named  "macro”  for  subsequent  command 
entry. 


b)  For  control  entry  merging,  command  names,  abbreviations,  or  option  codes  should  be 
accepted  as  if  those  control  entries  had  been  made  separately. 

c)  Required  punctuation  of  merged  entries  should  be  minimized.  A  standard  delimiter  in 
separating  commands  should  be  used;  e.g.,  a  slash  (/).  See  figure  9. 


List  Command  String:  SORT/SAVE/TRANSMrT 

Identify  command  key  sequence 

(ALT  or  CONTROL  +  <character>):  ALT  P 

Replace  old  "ALT  P"  ('SORT/SAVE') 

With  -SORT/SAVEyTRANSMIT-  (Y  or  N):l 


FIGURES.  Possible  dialog  to  establish  'macro'  command. 


Dialog/interactive  control  -  General 
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5.1. 1.5  Context  definition. 

a)  Transaction  context  should  be  provided  for  the  user, 

b)  Unless  contextual  interpretation  of  commands  would  have  destructive  effects  (e.g.,  data 
deletion),  transaction  control  software  should  interpret  current  control  actions  in  the  context  of 
previous  entries  without  requiring  users  to  reenter  data;  for  example,  requiring  users  to  specify  a 
text  name  during  repeated  text  entry/editing  and  related  operations.  Examples  of  context  definition 
are  presented  in  figure  1 0. 


Poor 

Better 

SAVE  'OCSOT  REPORT  REV.  3* 

<data  entry> 

SAVE  ‘OCSOT  REPORT  REV.  3* 

<data  entry> 

SAVE  ‘OCSOT  REPORT  REV.  3‘ 
TRANSMIT  ‘OCSOT  REPORT  REV.  3‘ 

SAVE  ‘OCSOT  REPORT  REV.  3‘ 

<data  entry> 

SAVE 

<data  entry> 

S^VE 

TRANSMIT 

FIGURE  10.  Examples  of  transaction  context  definition. 


c)  Users  should  be  able  to  request  a  summary  of  the  results  of  prior  transactions  to 
determine  present  status;  for  example,  waiting  in  a  print  queue. 

d)  When  context  for  transaction  control  is  established  in  terms  of  a  defined  operational 
mode,  the  operational  mode  should  be  displayed. 

e)  Users  should  be  able  to  review  control  parameters  that  are  currently  operative. 

f)  If  the  consequences  of  a  control  entry  will  differ  depending  upon  context  established  by  a 
prior  action,  a  continuous  indication  of  current  context  should  be  displayed. 

g)  When  performing  an  operation  on  a  selected  item,  the  item  should  be  highlighted. 

h)  Information  displayed  to  provide  context  for  transaction  control  should  be  distinctive  in 
location  and  format,  and  consistently  displayed  from  one  transaction  to  the  next. 

i)  Displayed  options,  command  entry  areas,  prompts,  advisory  messages,  and  other 
displayed  items  (titles,  time  signals,  etc.)  relevant  to  transaction  control  should  be  distinctive  in 
position  and  format. 

j)  Formats  should  be  consistent  from  one  frame  to  the  next. 
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5.1. 1.6  Abbreviations  and  acronyms. 

a)  Where  possible,  use  of  abbreviations  and  acronyms  should  be  avoided.  Where  not 
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possible,  standard  abbreviations,  acronyms,  and  display  codes  should  conform  to  MIL-STD-12, 


MIL-STD-411,  OR  MIL-STD-783. 


b)  New  acronyms,  if  required,  should  be  developed  according  to  the  rules  of  MIL-STD-12. 
Extent  of  deviation  from  abbreviation  rules  should  be  minimized. 

c)  Abbreviations,  mnemonics,  and  acronyms  should  not  include  punctuation. 

d)  When  abbreviations  are  used,  a  dictionary  of  abbreviations  should  be  provided  to  the 


user. 


e)  Abbreviations  should  be  unique,  distinct  and  unambiguous,  and  using  them  should  not 
confuse  the  user  or  add  to  system  operation  time. 

5. 1.1. 7  Labeling  and  terminology. 


a)  Consistent  terminology  for  transaction  control  should  be  adopted. 

b)  Congruent  names  for  control  functions  should  be  adopted;  e.g.,  SAVE  -  DELETE  vs.  FILE  - 
DESTROY. 

c)  Transaction  wording  should  be  consistent  with  user  guidance  and  frame  of  reference. 

d)  For  interpreting  user-composed  control  entries,  upper  and  lower  case  letters  should  be 
treated  as  equivalent. 

e)  The  length  of  individual  input  words  (commands,  keywords)  should  not  exceed  seven 
characters. 


5.1.1 .8  Promptinq/structurino. 

a)  The  system  should  contain  prompting  and  structuring  features  designed  to;  prompt  for  all 
required  input  parameters;  request  additional  or  corrected  information  from  the  user;  provide 
orientation  to  the  user  during  transactions;  and  indicate  when  errors  have  been  detected. 

b)  Prompts  should  inform  the  user  what  information  is  to  be  input. 

c)  Where  six  or  fewer  control  options  exist,  they  should  be  listed.  Where  more  input 
options  exist,  an  example  of  the  type  of  entry  that  is  required  should  be  presented. 

d)  The  system  should  prompt  for  all  required  input  parameters.  The  level  of  prompting 
detail  should  be  controllable  by  the  user. 
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e)  Prompting  messages  should  appear  at  a  standard  location  on  the  screen;  e.g.,  at  the 
beginning  of  the  next  line  to  be  typed,  in  the  data  field  where  an  entry  is  to  be  made,  at  a  command 
input  line,  or  within  a  menu  window  from  which  a  selection  will  be  made. 


5.1. 1.9  System  messages. 


a)  Message  language  should  be  distinct,  meaningful,  and  easily  discriminated. 
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b)  Humorous  or  sarcastic  messages  should  be  avoided. 

c)  Messages  should  make  the  user  feel  in  control. 

d)  Messages  should  not  present  the  system  as  a  person.  See  figure  1 1 . 


POOR 

BETTER 

1  AM  LOADING  THE  FILE 

YOU  REQUESTED... 

I'LL  BE  DONE  IN  A  BIT 

LOADING  FILE  TEST  DATA 

PLEASE  WAIT  . . . 

FIGURE  1 1 .  Examples  of  poor  and  better  system  messages 


e)  When  a  message  appears  on  the  screen,  both  the  content  of  the  message  and  the  action 
required  by  the  user  should  be  explicit. 

f)  Messages  detailing  the  users  status  (such  as  accounting  information,  files  in  use,  etc.) 
should  be  displayed. 


5.1.1.10  Feeci.b.acK. 

a)  Positive  feedback  should  be  provided  for  all  control  entries. 

b)  Completion  of  transaction  processing  should  be  indicated  by  feed  back  messages. 

c)  When  system  functioning  requires  the  user  to  standby,  periodic  feedback  should  be 
provided  to  indicate  normal  system  operation. 

d)  Successive  periodic  feedback  messages  should  differ  in  wording  from  presentation  to 
presentation,  or  be  otherwise  indicated.  An  example  of  periodic  feedback  messages  is  presented  in 
figure  12. 
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ist  — ► 

Processing  search  -  Please  wait 

Successive 

2nd  - ► 

Search  continuing  -  Please  wait 

periodic 

feedback 

3rd  - ► 

Processing  search  -  Wait  please 

messages 

final  — ► 

**  Search  Complete  ** 

FIGURE  12.  Example  of  periodic  feedback  message. 


5.1.1.11  Alarms. 

a)  Where  alarm  conditions  are  not  predefined  by  functional,  procedural,  or  legal 
requirements,  users  should  be  able  to  define  the  conditions  (in  terms  of  variables  and  values)  that 
will  result  in  computer  generation  of  alarm  messages. 

b)  Alarms  should  be  distinctive  and  consistent. 

c)  Users  should  be  provided  with  a  simple  means  of  acknowledging  and  turning  off 
noncritical  alarm  signals  without  erasing  any  displayed  message  that  accompanies  the  signal. 

d)  If  users  are  required  to  acknowledge  a  special  or  critical  alarm  in  some  special  way, 
acknowledgment  should  not  inhibit  or  slow  user  response  to  the  alarmed  condition. 

5.1.1.12  System  response  time. 

a)  Computer  response  time  to  user  entries  should  be  appropriate  to  time  constraints 
imposed  by  the  task  or  mission,  specific  data  processing  applications,  and  type  of  transaction. 

b)  The  guidelines  of  Table  3  should  be  used  as  guidance  for  maximally  acceptable  system 
response  time. 

c)  Temporary  keyboard/device  lockout  due  to  processing  of  transaction  control  entries 
should  be  minimized,  and  should  not  exceed  0.2  seconds. 

d)  Where  control  entries  must  be  delayed  pending  computer  processing  of  prior  entries, 
then  control  entry  should  be  acknowledged. 

e)  When  display  generation  is  slow,  the  user  should  be  notified  when  the  display  output  is 
complete. 
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TABLES.  Acceptable  system  response  times  for  routine  system  tasks 


System 

Interoretation 

Resoonse  Time  Definition 

Acceptable 
Response 
Time  fSecondst 

Key  Response 

From  key  depression  until  positive 
response;  e.g.,  "click*  or  display  echo 

0.1 

Key  Print  (echo) 

From  key  depression  until  appearance  of 
character 

0.2 

Page  Turn 

From  end  of  request  until  first  few  lines 
are  visible 

1 .0 

Page  Scan 

From  end  of  request  until  text  begins  to 
scroll 

0.5 

Data  Field 

Entry 

From  selection  of  field  until  visual 
verification 

0.2 

Function 

Selection 

From  selection  of  command  until 
response 

2.0 

Pointing 

From  input  of  point  to  display  of  point  or 
pointing  device 

0.2 

Drawing/ 

Sketching 

From  input  of  point  to  display  of  point, 
line.  arc.  etc. 

0.2 

Local  Update 

Change  to  image/display  using  local  data 
base.  e.g..  new  menu  list  display 

0.5 

Host  Update 

Change  where  data  is  at  host  in  a  readily 
accessible  form.  e.g..  a  display  scale  change 

2.0 

File  Update 

Image/display  update  requiring  access  to  a 
host  file 

10.0 

Simple  Inquiry 

From  command  until  display  of  a  common 
message 

2.0 

Complex  Inquiry 

Response  message  which  requires  seldom 
used  calculations  in  graphic  form 

10.0 

Error  Feedback 

From  entry  of  input  until  error  message 
appears 

2.0 
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f)  Control  response  time  variability  should  be  within  the  limits  of  figure  13. 


Control  Response  Time 

Variability 

0  to  2  seconds  - 

less  than  5% 

2  to  5  seconds  - 

less  than  10% 

greater  than  5  seconds  - 

less  than  15% 

FIGURE  13.  Maximum  control  response  time  variability. 


5.1.1.13  Dialog  type  selection. 

a)  Dialog  type  should  match  task  requirements  and  user  abilities.  The  guidance  below  and  in 
figure  14  should  be  used  to  make  dialog  type  selection  decisions. 


b)  Question  and  answer  dialog  may  be  used  for  routine  data  entry  tasks,  where  data  is  known 
and  ordering  can  be  constrained,  for  users  with  little  or  no  training,  and  where  computer  response 
is  expected  to  be  moderately  fast. 


c)  Form  filling  dialog  may  be  used  where  flexibility  in  data  entry  is  needed,  where  users  are 
moderately  trained,  where  computer  response  may  be  slow,  and  as  an  aid  for  composing  complex 
control  entries. 


d)  Menu  selection  dialog  may  be  used  for  tasks  that  involve  choice  among  a  constrained  set  of 
alternatives,  where  little  entry  of  arbitrary  data  is  required,  where  users  have  little  training, 

when  a  command  set  is  too  large  to  commit  to  user  memory,  and  where  computer  response  is 
relatively  fast. 

e)  Function  keys  may  be  used  in  conjunction  with  other  dialog  types  for  tasks  requiring  a 
limited  number  of  control  entries,  as  an  immediate  means  to  accomplish  frequent  or  control 
transactions,  or  for  criteria  control  entries  e.g.,  "help",  "cancel”,  etc.). 

f)  Command  language  dialog  may  be  used  for  tasks  involving  a  wide  range  of  control  entries, 
where  users  are  highly  trained  or  will  use  the  system  frequently,  and  for  tasks  where  control 
entries  may  be  mixed  with  data  entries  in  arbitrary  sequence. 


g)  Query  language  dialog  may  be  used  for  tasks  emphasizing  unpredictable  information 
retrieval  (as  in  many  analysis  and  planning  tasks)  with  moderately  trained  users. 


h)  Constrained  natural  language  dialog  may  be  used  in  applications  where  task  requirements 
are  broad  ranging  or  poorly  defined,  and  where  little  user  training  can  be  provided. 
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5.1.2 


a)  Questions  should  be  displayed  separately,  posing  of  compound  questions  should  be  avoided 


b)  When  computer  posed  questions  are  interrelated,  answers  to  previous  questions  should  be 
displayed:  users  should  not  be  required  to  remember  prior  answers  to  provide  context  for  current 
questions.  An  example  of  a  question  and  answer  dialog  which  provides  context  is  presented  in  figure 


15. 


Lock  on  target  ’14'?:  Y 
Illuminate  target?:  Y 

Continuous  track  update?:  Y 
Initiate  engagement  sequence?:  | 

Y-Yes  N-No  D-Drop  Track  N-New  E-Exit  I 
FIGURE  15.  Example  question  and  answer  dialog  providing  context 


c)  As  appropriate,  question  sequence  should  be  compatible  with  source  documents. 

5.1 .3  Form  filling  dialog.  In  addition  to  the  guidelines  contained  here,  the  guidelines  of  section 
5.2,  "Data  Entry",  and  Section  5.2.4,  "Form  Entry",  should  be  applied  to  the  design  of  form  filling 
dialogs. 


a)  As  appropriate,  defaults  for  control  entry  in  form  filling  should  be  provided. 

b)  Control  forms  and  formats  should  be  presented  in  a  consistent  and  logical  format. 

5.1.4  Menu  selection  dialog. 

a)  Each  related  group  of  menu  options  should  permit  only  one  selection  by  the  user.  Where 
multiple  options  can  be  selected,  they  should  be  identified,  by  label  (e.  g.,  "Check  Selections 
Desired")  or  by  option  coding. 

b)  All  available  options  should  be  explicitly  and  com^-ietely  displayed  for  a  selected  menu. 

c)  Users  should  be  able  to  distinguish  between  available  and  unavailable  options. 

d)  Unavailable  menu  options  should  be  displayed  along  with  available  options. 

Dialog/interacfive  control  -  Menu  selection  dialog 
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e)  An  input  prompt  should  clearly  indicate  to  the  user  that  the  computer  is  waiting  for  a 
response  and  a  standard  symbol  should  be  used  for  prompting  entry. 

f)  Feedback  for  menu  selection  should  be  provided. 


Select  all  or  any 

Select  one 

Display: 

C  -  Color  enabled 

G  -  Graphics  res 

Control: 

K  -  Keyboard  commands 
M  -  Display  Menus 

L  -  Load  a  File 

S  Save  File  - _ 

R  -  Rename  File 

P  -  Print  Document 

Q  •  Quit 

Input  selections:  C/K/M/L  f 

Nonactive 

options 


FIGURE  16.  Example  of  a  menu  selection  screen 


5.14.1  Format. 

a)  Logically  related  options  within  a  list  should  be  grouped,  and  groups  should  be  segregated 
by  lines  or  other  means. 

b)  Unless  constrained  by  available  display  space,  related  menu  options  (PRINT  commands, 
FILE  commands,  etc.)  should  be  formatted  as  a  single  column  list. 

c)  Menu  options  should  be  logically  ordered  and  grouped,  by  frequency  of  use,  importance, 
functional  relations,  or  sequence  of  use. 

d)  Where  ordering  cannot  be  determined  by  frequency  of  use,  importance,  functional 
relations,  or  sequence,  alphabetic  ordering  should  be  used. 

e)  Menus  provided  in  different  displays  orconte  'ts  should  be  designed  so  that  option  lists 
are  consistent  in  wording  and  ordering. 

f)  Pop-up,  pull-down,  and  windowed  menus  should  be  displayed  in  consistent  screen 
locations  for  all  modes,  transactions,  and  sequences. 

g)  Menus  should  be  distinct  from  other  displayed  information. 

5. 1.4. 2  Labeling  and  terminology. 

a)  An  explanatory  title  for  each  menu  should  be  provided.  Where  menu  options  are  grouped 
in  logical  subunits,  each  group  should  be  provided  a  descriptive  label  that  is  distinctive  in  format 
from  the  option  labels  themselves. 

Dialog/interactive  control  -  Menu  selection  dialog 


b)  Menu  options  should  be  worded  as  commands  rather  than  as  questions  to  the  user. 

c)  When  menu  selection  is  used  in  conjunction  with  command  language,  menu  option  wording 

4  1 


MIL-HDBK-761A 


should  be  consistent  with  command  language. 

5. 1.4. 3  Menu  option  selection. 

5.1. 4.3.1  Pointing  and  selecting. 

a)  Menu  selection  from  displayed  options  should  be  implemented  by  direct  pointing  (touch 
display,  lightpen,  etc.),  or  indirect  pointing  (mouse,  trackball,  etc.)  devices. 

b)  vyhere  direct  pointing  devices  are  used  in  menu  selection,  a  sufficient  pointing  area 
should  be  provided  to  preclude  selection  errors.  See  figures  17. 

c)  Where  indirect  pointing  devices  are  used  in  menu  selection,  a  large  pointing  area  for 
option  selection  should  be  provided,  including  the  area  of  the  displayed  option  label,  plus  a 
half-character  distance  around  the  label.  See  figure  18. 

d)  When  menu  selection  pointing  is  via  cursor  control  keys  or  tabbing,  the  cursor  should 
automatically  be  placed  at  the  first  listed  option. 

e)  Experienced  users  should  be  able  to  bypass  a  series  of  menu  selections  and  make  an 
equivalent  command  entry  directly,  without  using  pointing  or  cursor  control  devices. 

f)  When  equivalent  keyboard  commands  are  provided  as  means  of  menu  selection,  they 
should  be  displayed  as  part  of  the  menu  option  label.  See  figure  19. 

5.1. 4.3.2  Key  coded  menu  selection. 

a)  Menu  selection  by  keyed  entry  may  be  used  when  menu  selection  is  a  secondary  or 
occasional  means  of  control  entry,  or  where  short  option  lists  are  needed. 

b)  Options  should  be  coded  by  the  first  letter  or  several  letters  of  their  displayed  labels, 
rather  than  by  arbitrary  numeric  codes. 

c)  When  menu  items  are  coded,  a  standard  display  area  for  code  entry  should  be  provided, 
and  the  cursor  should  be  placed  in  the  command  entry  area. 

d)  Codes  associated  with  each  option  should  be  displayed  in  a  consistent,  distinctive  manner. 

e)  One  (1)  letter  codes  for  menu  selection,  rather  than  assigning  arbitrary  letter  or 
number  codes,  should  be  provided.  See  figure  20. 

f)  Coding  of  menu  options  should  be  consistent  ar^ong  display  screens  and  system  use 
contexts. 
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The  menu  bar  displayed  at  the  bottom  of  this  figure  is  distinct 
from  the  text  which  might  be  entered  here.  In  this  exaitple,  the 
information  is  remotely  located  from  the  input  text,  is  enclosed 
in  boxes,  and  item  selected  is  in  inverse  video.  Other  means  can  be 
devised,  such  as  using  different  colors,  fonts,  display  windows,  font 
size,  and  delimiters.  In  this  example,  the  options  presented  are 
for  several  file  and  editing  operations  that  may  be  frequently 
required  by  system  users.  The  segregated  data  could  also  be 
listings  of  frequently  used  commands  (e.g.,  "Option  -  S  to  SAVE"), 
system  advisory  or  status  information  ("132  Kilobytes  available 
memory  space  remaining."  or  "File  not  saved  for  last  40  minutes."), 
or  for  display  of  any  message  tr-jffic  ("To  all  system  users,  system 
security  briefing  at  0930  hours  today.") 

Note  that  the  'Send'  option  below  is  highlighted  to  indicate  it 
is  the  selected  option.| 


Save 


Send 


Delete  Revert  Print  I  I  Quit 


FIGURE  17.  Ex 


MIL-HDBK- 


Don't  use  a  small  area 
which  Is  more  difficult 
to  point  Into 
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Menu  Items  eppear 
by  indirect  pointing 
device 


Labels  Include  equivalent 
keyboard  commands 


-IGURATION 


Selected  option  highlighted 


I  A  1 1  r  I  h  u1 s  CIK  A 


Pointing  cursor 


Zw 


Denotes  previously 
selected  and  active  option 


Diagram  item 
selected  for 
display  of 
attributes  Is 
highlighted 


FIGURE  19. 


POOR 

BETTER 

1  -  Identify  Friend  or  Foe 

2  -  Lock  on  target 

3  -  Assign 

4  -  Engage 

5  -  Assess  Kill 

1  -  Identify  Friend  or  Foe 

L  -  Lock  on  target 

A  -  Assign 

E  -  Engage 

K  -  Kill  assessment 

FIGURE  20. 
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5. 1.4.4  Hierarchic  menu  design. 

a)  When  menu  selection  must  be  made  from  a  long  list,  hierarchic  menus  for  sequential 
selection  should  be  provided,  but  the  number  of  hierarchic  levels  should  be  minimized. 

b)  Each  menu  option  list  should  have  4  to  8  options,  menus  with  less  than  3  options  should 
be  avoided. 

c)  A  general  menu  of  basic  options,  as  the  top  level  menu,  should  be  provided  which  is  as 
unambiguous  as  possible. 

d)  Menu  elements  subordinate  to  top  level  menus  should  be  logically  related;  e.g.,  FILE 
transactions,  PRINT  transactions,  EDIT, etc. 

e)  Hierarchic  menus  should  be  structured  to  permit  immediate  user  access  to  critical  or 
frequently  selected  options  and  should  minimize  the  number  of  steps  required. 

f)  Users  should  have  to  make  only  one  control  action  to  move  to  the  next  higher  level,  and  a 
separate  simple  control  action  to  return  to  the  general  menu  at  the  top  level. 

g)  Design  and  use  of  hierarchic  menus  should  be  consistent  across  task  and  transaction 
contexts. 

h)  The  current  position  within  menu  structures  should  be  indicated  when  hierarchic  menus 
are  used. 

i)  Hierarchic  menu  control  options  should  be  distinct  from  menu  ..rancf..ng  options. 

5.1.5  Command  language  dialog. 

a)  Once  a  command  has  been  composed,  an  explicit  enter  or  execute  should  be  provided. 

b)  Standard  techniques  for  editing  commands  should  be  provided. 

c)  If  a  command  entry  is  not  recognized,  user  should  be  able  to  revise/replace  the  command. 

d)  If  a  command  entry  may  cause  delays,  delete  or  modify  data,  or  have  other  potentially 
adverse  consequences,  the  user  should  be  required  to  review  and  confirm  a  displayed  interpretation 
of  the  command  before  it  is  executed. 

5  1.5.1  Labeling  and  terminology. 

a)  Command  language  should  be  designated  so  that  a  user  can  enter  commands  in  terms  of 
functions  desired. 

b)  Command  names  and  language  should  be  meaningful,  use  familiar  wording,  and  be 
distinctly  and  consistently  worded. 
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c)  Codes  should  be  designed  to  aid  memory. 

d)  If  a  system  will  have  many  novice  or  infrequent  users,  the  system  should  recognize  a 
variety  of  synonyms  or  alternative  syntax  for  each  word  defined  in  the  command  language. 

e)  Where  possible,  commands  should  be  selected  such  that  common  misspelling  errors  do  not 
represent  valid  commands  (e.g.,  DEL  for  Delete  and  SEL  for  Select,  would  be  a  common  error  since 
the  characters 'd'  and  's‘  are  adjacent  on  QWERTY  keyboards). 

f)  Words  and  abbreviations  in  a  command  language  should  be  distinctive.  For  example, 

'FILL'  (a  graphic  command)  and  'FILE'  (a  file  operation  command)  are  too  similar,  use  of  'PAINT' 
and  'FILE',  or  'FILL'  and  'SAVE'  would  be  preferred. 

g)  Commands  should  not  consist  only  of  non-alphanumeric  characters  (e.g.,  "$."  as  a 
command  to  stop  printing.  If  "$"  were  a  system  attention  .symbol,  then  "SS"  would  be  a  better 
command  to  stop  printing). 

5.1. 5.2  Format,  syntax  and  layout. 

a)  A  standard  display  area  for  command  entry  should  be  provided.  When  possible,  command 
entry  should  be  located  at  the  bottom  of  the  screen. 

b)  Command  language  functions  should  be  organized  in  groups  for  ease  of  learning  and  use. 

c)  For  infrequent  or  untrained  users,  syntactic  complexity  should  be  minimized. 

d)  Command  language  syntax  should  be  consistent  across  different  transactions.  For 
example,  use  of  special  symbols  such  as  quotation  marks,  key  use  (OPTION,  COMMAND,  ETC.),  and 
sequence.  See  figure  21 . 


POOR 

BETTER 

SAVE  AS  WEAPON  FILE  <ENTER> 

SAVE  AS  WEAPON  FILE  <ENTER> 

WEA.  ON  FILE  DELETE  <RETLIRN> 

DELETE  WEAPON  FILE  <ENTER> 

WEAPON  FILE  RENAME  WEP  1  <ENTER> 

RENAME  WEAPON  FILEMfEP  1  <ENTER> 

Examples  of  poor  and  better  command  consistency. 


FIGURE  21. 
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5.1 .5.3  Keying  requirements. 

a)  Required  use  punctuation  should  be  minimized;  where  required,  a  standard  delimiter 
(such  as  a  /)  should  be  used. 

b)  Blanks  in  command  entry  should  be  ignored  by  the  system. 

c)  Users  should  be  able  to  use  abbreviated  forms  of  any  command  of  more  than  5  characters. 

5. 1.5.4  Job  performance  aids. 

a)  Users  should  be  able  to  request  guidance  information  necessary  to  determine  required 
parameters  or  options  in  a  command  entry,  or  to  determine  available  options  for  a  command. 

b)  Where  possible,  guidance  information  should  be  accompanied  with  graphic  examples  of 
command  content  and  syntax. 

c)  A  general  list  of  basic  commands,  with  appropriate  command  format,  should  be  provided. 
5.1.6  Query  and  natural  language  dialogs. 

5. 1.6.1  Terminology. 

a)  The  wording  of  a  query  should  specify  what  data  are  requested,  not  how  to  find  the  data. 

b)  A  query  language  should  be  designed  so  that  it  reflects  a  natural  data  structure  or 
organization. 

c)  Users  should  be  able  to  employ  alternative  forms  when  composing  queries,  for  example: 

"Updata  target  display  within  3  miles" 

"Updata  target  display  in  a  three  mile  radius" 

"Updata  target  display  out  three  miles." 

d)  Where  possible,  need  for  quantifiers  ("less",  "without",  "excluding")  in  specifying 
queries  should  be  minimized. 

5. 1.6. 2  Limiting  and  combining  queries. 

a)  When  a  query  may  result  in  a  large-scale  data  retrieval,  the  user  should  be  required  to 
confirm  the  transaction  or  take  further  action  to  narrow  the  query  before  processing. 

b)  Query  language  should  include  logic  elements  that  permit  users  to  link  sequential  queries 
as  a  single  entry,  such  as  "and",  "or",  etc. 

c)  A  query  language  should  be  capable  of  linking  sequential  queries  by  use  of  statements  such 
as,  "of  those  records  retrieved..."  or  "how  many  of  the  remaining  candidates..." 
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5.1.7  Function  kevs. 

5.1. 7.1  Labeling  and  identifying. 

a)  Function  keys  should  be  distinctively  labeled. 

b)  If  key  function  is  variable,  current  active  function  should  be  appropriately  labeled  by 
adjacent  screen  location  or  other  means. 

c)  Function  keys  status  (e.g.,  active  -  inactive)  should  be  indicated.  Unneeded  or  disabled 
function  keys  should  be  disabled  and  so  indicated  by  the  system.  See  figure  22,  below. 
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Current  key  functions 
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status  is  coded 
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5. 1.7.2  Single  and  double  keying. 

a)  Keys  controlling  frequently  used,  critical,  or  lime  constrained  functions  should  permit 
single  key  action  and  should  not  require  double  keying  (e.g.,  <Control>-  FI ,  or ,  <Option>  -  SAVE). 

b)  Double-keyed  functions  should  be  logically  paired  and  consistently  logical. 

c)  Keys  should  perform  labeled  functions  with  a  single  activation,  and  should  not  change  its 
function  with  repeated  (e.g.,  double  stroke)  activation. 

5. 1.7.3  Feedback. 

a)  Feedback  should  be  provided  for  function  key  activation,  particularly  when  activation 
does  not  result  in  any  immediate  observable  response. 

b)  When  system  functioning  requires  the  user  to  standby,  periodic  feedback  should  be 
provided  to  indicate  normal  system  operation. 

5.1. 7.4  Format  and  layout. 

a)  Function  keys  should  be  grouped  in  distinctive  locations  on  the  keyboard. 

b)  Frequently  used,  important,  or  critical  function  keys  should  be  placed  in  the  most 
convenient  locations. 

c)  The  layout  of  function  keys  should  be  compatible  with  their  importance. 

d)  Physical  protection  should  be  provided  for  keys  with  potentially  disruptive  consequences, 
such  as  CLEAR  MEMORY. 

5. 1.7.5  Modes/function. 

a)  When  a  function  is  continuously  available,  the  function  should  be  assigned  to  a  single  key. 

b)  Key  functions  in  different  operational  modes  should  be  consistent  or  similar.  For 
example,  when  a  key  (e.g.,  "FI")  confirms  data  changes  in  one  mode,  it  may  confirm  message 
transmission  in  another  (the  confirmation  function  is  the  same). 

c)  When  the  functions  assigned  to  a  set  of  keys  change  as  a  result  of  user  selection,  the  user 
should  be  provided  an  easy  means  to  return  to  the  base-level  functions. 

d)  Where  possible,  experienced  users  should  be  able  to  define  their  own  key  functions  (for 
example,  a  repetitive  transaction  sequence  such  as  FIND  -  [field  value]-  REPLACE  [field  value]  - 
WITH  [field  value]  -  SAVE  RECORD,  may  be  assigned  temporarily  to  a  function  key). 
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5.1.8  Iconic  interaction. 

a)  Icons  may  be  used  to  graphically  represent  operations,  processes  and  data  structures,  and 
may  be  used  as  means  of  exercising  control  {e.g.,  by  selecting  an  icon  and  commanding  operations 
such  as  DELETE,  COPY,  PRINT)  over  system  functions,  components,  and  data  structures. 

b)  Iconic  representations  should  not  be  used  when  display  resolution  is  low. 

c)  If  icons  are  used  to  represent  control  actions  in  menus,  a  label  should  be  associated  with 
each  icon. 

d)  Icons  should  be  consistent  and  predictable  across  operating  modes  and  across  applications. 

e)  Icons  si"  juld  be  graphically  designed  to  the  processes  or  operations  they  represent,  by  use 
of  literal  (e.g.,  a  figure  of  an  aircraft),  functional  (e.g.,  a  figure  representing  a  network),  or 
operational  (e.g.,  pen  in  hand  on  paper)  representations. 

0  Abstract  or  humorous  representations  should  be  avoided.  Examples  of  of  literal, 
functional,  and  operational  icons  are  presented  in  figure  23. 

g)  Icon  manipulation  should  occur  as  recommended  in  section  5.2.6  "Graphics  Entry"  of  this 
document. 


FIGURE  23.  Examples  of  icons 
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5.1.9  User  transaction  interrupts. 

a)  Means  to  interrupt  or  cancel  transactions  should  be  provided,  should  be  distinctive  (e.g., 
PAUSE  and  STOP  may  be  confused,  as  well  as  STOP  and  END),  and  should  occur  only  by  explicit  user 
action. 

b)  User  interrupts  and  aborts  should  not  modify  or  remove  stored  or  entered  data. 

c)  As  appropriate  to  specific  transactions,  the  following  interrupts  should  be  provided: 

1 .  CANCEL  (or  UNDO)  should  erase  any  immediate  changes  (e.g.,  a  drawn  line,  or 
typed  text  string)  and  restore  the  display  to  its  previous  version. 

2.  BACKUP  should  return  the  display  to  the  last  previous  transaction. 

3.  REVIEW  should  return  to  the  first  display  in  a  defined  transaction  sequence, 
permitting  the  user  to  review  a  sequence  of  entries  and  make  necessary  changes. 
REVIEW  should  be  nondestructive. 

4.  RESTART  or  REVERT  should  cancel  any  entries  made  in  a  defined  transaction 
sequence  and  return  to  the  state  at  the  beginning  of  the  sequence  (e.g.,  reload  a 
file,  clear  all  entered  data  since  file  load,  etc).  When  data  entries  or  changes  will 

be  nullified  RESTART  action,  users  should  be  required  to  CONFIRM  the  RESTART. 

5.  END  (or  EXIT)  should  conclude  a  repetitive  transaction  sequence. 

6.  PAUSE  and  CONTINUE  should  temporarily  interrupt  a  transaction  sequence 
without  change  to  data  or  control  logic.  When  PAUSE  is  selected,  a 
PAUSE  status  indication  should  be  presented. 

7.  SUSPEND  should  preserve  (save)  current  transaction  status  when  a  user  leaves 
the  system,  and  resume  at  that  point  when  the  user  again  logs  on  the  system. 

When  SUSPEND  is  selected,  an  indication  of  the  SUSPEND  status  should  be 
presented. 

5.1.10  Error  management. 

a)  Users  should  be  able  to  edit  a  command  during  its  composition  before  making  an  explicit 
ENTER  action,  and  should  be  able  to  stop  a  control  process  at  any  point  in  a  sequence  to  correct  an 
error. 


b)  Interface  software  should  deal  appropriately  with  all  possible  control  entries,  correct 
and  incorrect. 

c)  System  and  software  should  be  able  to  distinguish  between  program  errors,  equipment 
failures,  and  operator  errors  and,  where  failures  result  in  shutdown,  allow  for  minimum  loss  of 
work  performed. 
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5.1.10.1  Error  detection. 

a)  If  only  a  portion  of  a  merged  command,  or  an  entered  string  of  commands,  can  be 
executed,  the  user  should  be  alerted  and  guidance  provided  to  permit  correction,  completion,  or 
cancellation  of  the  merged  command. 


**  ERROR  •* 

Unable  to  execute  command  string; 

LOAD/FIND  ‘FOXBAT.DATAVPRINT 
ERROR  ->  File  not  found 

FI  -  REDO  FROM  START  F2  -  EDIT  COMMAND  STRING  F3  -  CANCEL 


FIGURE  24.  Example  of  error  messane. 


b)  When  an  error  is  defected  in  a  string  of  command  entries,  the  system  should  either 
consistently  execute  to  the  point  of  error,  or  consistently  require  users  to  correct  errors  before 
execution. 

c)  If  a  menu  selection,  function  key,  command,  etc.  entered  is  invalid  or  inoperative  at  the 
time  of  selection  (e.g.,  attempting  to  print  a  document  from  within  an  edit  mode),  no  action  should 
result  except  a  display  of  an  advisory  message  indicating  what  functions,  options,  or  commands  are 
appropriate. 

d)  When  appropriate,  the  display  should  provide  troubleshooting  alternatives  to  aid  in 
locating  the  problem  which  caused  the  error. 

5.1.10.2  Error  messages. 

a)  Error  messages  should  indicate  why  control  input  was  rejected  and  what  corrective 
actions  may  be  taken.  Where  possible,  error  messages  should  distinguish  between  syntax  errors 
(such  as  use  of  a  wrong  delimiter)  and  keying  errors  (such  as  misspelling  a  command). 

b)  Error  messages  and  guidance  that  will  not  fit  on  the  display  should  contain  references  to 
on-line  documentation  which  will  provide  further  guidance,  users  should  not  have  to  refer  to 
secondary  written  procedural  references. 

c)  Error  messages  should  be  displayed  with  the  rejected  input  and  the  portion  of  the  input  in 
error  should  be  highlighted.  An  example  of  a  highlighted  portion  of  an  error  message  is  presented 
in  figure  25. 
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**  ERROR  ** 

Unable  to  interpret  command  string; 


LOAD  'Air.Data'/FiND  'FOXBAT-DATAV 


RINT 


ERROR  ->  Command  name  not  recognized 
F1  -  REDO  FROM  START  F2  -  EDIT  COMMAND  STRING  F3  -  CANCEL 


FIGURE  25.  Error  message  which  highlights  unifucroreted  command  segment 


5.1.10.3  Error  correction  and  recovery. 

a)  When  a  command  entry  is  in  error,  is  not  recognized  or  is  not  appropriate,  users  should 
be  able  to  correct,  without  reentering,  the  command. 

b)  Entry  of  corrections  should  require  an  explicit  action,  and  should  require  the  same 
ENTER  action  for  reentry  that  was  used  for  the  original  entry. 

c)  Easy  means  to  return  to  the  main  dialog  after  error  correction  should  be  provided. 
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5.2  Data  entry. 

5.2.1  General. 

5. 2. 1.1  System  response  lime  and  user  pacing. 

a)  The  system  should  acknowledge  user  inputs  rapidly,  preferably  within  0.2  seconds  after 
data  entry. 

b)  Users  should  be  able  to  pace  data  entry,  without  limitations  controlled  by  computer 
processing  or  external  events. 

5. 2. 1.2  Editing  during  entry. 

a)  Users  should  be  able  to  perform  simple  editing  during  data  entry,  without  entering 
special  editing  modes  (for  exa  nple,  by  use  of  destructive  backspace  to  erase  and  retype  characters 
to  the  immediate  left  o.  the  cursor). 

b)  Users  should  be  abie  to  change  entries  by  consistent  means;  e.g.,  exclusive  use  of 
typeoveror  DELETE/INSERT. 

c)  Users  should  be  able  to  enter  data  via  a  consistent  mode  (keyboard,  lightpen,  mouse,  etc), 
without  having  to  change  modes. 

d)  When  inserting  words  or  phrases,  items  to  be  inserted  should  be  displayed  as  ’he  final 
copy  will  appear. 

e)  During  input  data  editing,  the  system  should  automatically  display,  or  offer  to  display 
via  prompt,  information  to  be  modified. 

5. 2. 1.3  Data  entry  feedback. 

a)  Data  entered  should  appear  on  the  users  primary  display  on  a  stroke-by-stroke  basis. 

b)  The  system  should  confirm  completion  of  a  data  entry  action  by  display  of  confirmation 
message  or  other  means  k  indicate  successful  data  entry. 

c)  Error  messages  should  be  displayed  to  indicate  unsuccessful  aaici  entry. 

d)  Feedback  should  be  provided  for  repetitive  data  entries  (e.g.,  duplication  field  entries 
within  forms  or  from  previous  forms)  by  system  regeneration  of  data  entries. 

e)  The  user  should  be  alerted  when  the  system  cannot  interpret  or  recognize  an  abbreviated 
data  entry.  Where  possible,  the  system  should  question  tne  user  to  resolve  uncertainty. 
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5.2.1. 4  Data  entry  defaults- 

a}  Where  inputs  have  consistent  data,  the  user  should  be  able  to  define  default  values,  codes 
or  strings.  The  system  should  carry  the  data  to  subsequent  forms,  text  strings,  etc. 

b)  When  default  modes  are  provided,  the  user  must  be  able  to  define,  modify,  remove, 
inhibit  or  enable  defaults  at  any  time. 

c)  Users  should  be  capable  of  replacing  any  data  entry  default  value  with  a  different  entry 
without  changing  the  default  definition  for  subsequent  fields. 

d)  On  initiation  of  a  data  entry,  defined  default  values  should  be  automatically  displayed  and 
highlighted. 

e)  The  user  should  be  able  to  press  one  key  to  confirm  the  default  values.  See  figure  26. 


Sweep  Area  (degrees): 
Azimuth  (degrees): 
Sweep  speed  (CPS): 


360 
3  0 
2 


ENTER  to  Accept  TAB  to  field  to  change 


FIGURE  26.  Example  of  screen  display  of  automatic  default  values. 

5.2. 1.5  Hiahlighting. 

a)  Highlighting  should  should  be  easily  recognizable  and  be  used  to  attract  the  users 
attention  to  active  fields,  special  conditions,  or  as  a  means  to  provide  feedback. 

b)  Highlighting  should  not  interfere  with  the  readability  of  displayed  information. 

c)  A  highlighting  technique  similar  to  that  used  on  the  VDT  should  be  provided  for  printed 

output. 


d)  Critical  data  should  bo  highlighted  and  should  be  removed  when  it  no  longer  has  meaning, 
importance,  or  criticality. 

e)  Flashing  should  not  be  used  as  a  means  to  highlight  routine  information.  Flashing  should 
only  be  used  as  an  alerting/alarming  code. 
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5.2. 1.6  Data  entry  fields. 

a)  A  clear  visual  identification  of  each  field  should  be  provided. 

b)  Field  delineation  cues  should  distinguish  basic  features  of  required  entries,  i.e., 
maximum  acceptable  length,  order  of  entry  and  data  type.  For  example,  a  broken  underscore  for 
required  entry,  dots  for  )ptional  entries,  and  asterisks  for  variable  length  entries. 

c)  Active  data  entry  fields  should  be  indicated  by  highlighting  or  other  means  and  should 
provide  data  entry  prompts. 

5. 2. 1.7  Explicit  user  actions. 

a)  In  general,  explicit  user  actions  should  be  required  to  initiate  system  processing,  such  as 
saving,  deleting  data  or  files,  and  should  not  occur  as  a  result  of  other  system  commands  (e.g. 
renaming  a  file,  printing  a  file,  etc.). 

b)  An  explicit  ENTER  action  should  be  required  to  initiate  processing  of  entered  data;  an 
explicit  CANCEL  action  should  be  required  to  cancel  a  data  entry;  and  an  explicit  DELETE  action 
should  be  required  prior  to  deleting  any  text  or  other  data. 

5. 2. 1.8  Keying. 

a)  Where  possible,  users  should  be  able  to  use  single  keystrokes  to  enter  data.  Required 
multiple  keying  (Shift-key,  Option-key,  Command-key,  etc)  should  be  avoided. 

b)  For  data  entry,  upper  and  lower  case  keys  should  be  treated  as  equivalent. 

c)  When  entering  decimal  data,  the  system  should  reconnize,  out  not  require,  terminal 
decimal  points,  and  should  recognize,  but  not  require,  typing  of  leading  or  trailing  zeroes. 

d)  The  system  should  treat  multiple  and  single  spaces  as  equivalent.  Users  should  not  be 
required  to  count  spaces. 

e)  Keying  redundant  data,  data  already  known  by  the  system  (entering  both  account  number 
and  user  name  if  one  specifies  the  other),  or  data  that  can  be  computed  or  derived  should  not  be 
required  except  for  special  conditions  such  as  data  security.  A  glossary  should  link  information 
from  a  record  at  time  of  entry  so  that  keying  any  of  the  unique  elements  will  retrieve  a  whole 
record. 


f)  Coded  input  data  (alpha  or  numeric)  should  be  kept  short,  preferably  not  exceeding  5-7 
characters. 

g)  Long  input  data  strings  should  be  partitioned,  as  in  telephone  numbers,  into  shorter 
groups  of  three  to  five  characters,  separated  by  blanks,  hyphens,  or  slashes,  for  both  entry  and 
display. 
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a)  When  analog  data  input  is  based  on  qraphin  presentation  of  information  (si!<"h  sr  bearing 
vectors  on  a  tactical  display),  analog  means  of  data  entry  should  be  provided.  For  example,  a 
continuous  rotary  switch  should  be  used  to  input  bearing  estimations  from  radar  displays. 

b)  Where  analog  data  is  based  on  previously  quantified  data,  key  entry  should  be  used  in  lieu 
of  analog  entry.  For  example,  entry  of  verbal  bearing  reports  ("Target  bearing  two  two  five") 
should  be  entered  using  numeric  keysets. 

5.2.1 .10  Hierarchical  data  input.  If  a  user  must  enter  hierarchical  data,  the  system  should  guide 
the  specification  of  relations  in  hierarchical  structures. 

5.2.1.11  Recurrent/derived  data  input. 

a)  When  possible,  routine  data  that  can  be  derived  from  computer  records  should  be  entered 
automatically.  For  example,  do  not  require  a  user  to  identify  a  work  station,  current  date,  or  time. 

b)  When  possible,  computation  of  derived  data  should  be  provided. 

c)  Recurrent  field  entries  should  be  retrievable  for  user  acceptance. 

d)  Where  data  that  are  logically  related  to  other  entries  are  accessible  to  the  computer,  the 
computer  should  retrieve  and  enter  those  redundant  data  items  automatically  (for  example,  when  an 
item  name  specifies  an  identification  code). 

e)  Cross-file  updating  should  be  provided  by  the  system.  Users  should  not  have  to  perform 
cross-file  updates  (for  example,  separate  personnel,  timekeeping,  payroll,  and  voucher  files 
should  not  have  to  be  manually  cross-filed). 

5.2.1.12  Speech  input. 

a)  Speech  input  should  be  used  only  when  more  reliable  methods,  such  as  keying  or  pointing, 
cannot  be  used. 

b)  Speech  input  should  not  be  used  as  a  means  of  transaction  control  when  a  large 
constrained  vocabulary  may  exceed  memory  capabilities  of  the  user,  or  for  highly  complex  or 
nebulous  operations. 

c)  A  limited  speech  input  vocabulary  should  be  used  and  spoken  entries  should  be 
phonetically  distinct. 

d)  Input  feedback  and  simple  error  correction  procedures  should  be  provided  for  speech 

input. 


e)  Alternative  entries  for  speech  input  should  be  provided,  as  in  the  use  of  EXIT,  FINISHED, 
and  QUIT  to  terminate  a  session. 

Data  entry  -  General”! 


0  Provide  PAUSE  and  CONTINUE  or  RESUME  option  for  speech  input. 

g)  Where  wo^d  boundaries  (pauses  between  words)  are  required  for  system  interpretation, 
boundaries  of  1 00  milliseconds  cr  more  should  be  allowed  by  the  system. 
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h)  A  word  reject  capability  should  be  provided. 

5.2.2  Cursor  positioning. 

a)  Cursors  should  be  distinctive  and  easy  to  locate  at  any  position  on  the  display  and  should 
be  easily  tracked  as  it  is  moved  through  the  display. 

b)  Cursors  should  not  obscure,  distract  or  impair  searching  for  information  unrelated  to 
the  cursor. 


c)  Cursor  positions  should  remain  stable  until  commanded  by  the  user  or  the  system  to 
move,  an  explicit  action  should  be  required  to  enable  or  activate  a  designated  cursor  position. 

d)  Cursor  controls  should  provide  fast  and  accurate  cursor  placement;  entry  of  a  designated 
cursor  position  should  be  acknowledged  within  0.2  seconds. 

e)  Control  actions  for  cursor  positioning  should  correspond  to  direction  of  cursor 
movement. 


f)  Where  cursor  positioning  is  required  as  part  of  a  keyed  data  entry  task,  the  cursor 
control  device  should  be  located  near  to,  or  integral  with,  the  keyboard. 

5.2.2. 1  Data  entry  and  cursor  placement. 


a)  An  ENTER  action  for  data  items  should  result  in  entry  of  all  items  regardless  of  where  the 
cursor  is  placed  on  the  display.  The  user  should  not  be  required  to  move  the  cursor  to  a  specific 
field  of  a  display  to  perform  an  enter  action. 

b)  User  required  actions  for  cursor  movement  should  be  mmimal  ^or  form-filling  entry. 


c)  The  TAB  key  should  be  used  to  move  the  cursor  to  the  next  data  field. 

d)  The  TAB  key  should  not  signify  ENTER  or  acceptance  of  field  contents. 

e)  Formats  should  be  organized  to  minimize  positioning  movements  of  the  cursor.  If  there 
is  a  predefined  HOME  position  for  the  cursor,  it  should  be  consistently  positioned  on  displays  of  the 
same  type. 


0  Users  should  not  be  able  to  move  cursors  to  data  fields  which  cannot  accept  data  or  where 
existing  data  cannot  be  modified. 


Data  entry  -  Cursor  positioning 


5.2  2.2  Gross  posilioning/pointina. 

a)  If  proportional  spacing  or  variable  sized  characters  are  used,  the  system  should 
automatically  place  the  cursor  in  the  correct  position  for  entering  or  changing  data. 

b)  When  cursor  positioning  is  accomplished  in  discrete  steps,  consistent  movement 
magnitudes  should  be  provided  for  horizontal  steps  and  vertical  steps.  However,  horizontal  steps  do 
not  need  to  be  of  the  same  magnitude  as  vertical  steps. 
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c)  When  cursors  are  used  in  selecting  display  areas  (pointing  to  menu  items,  etc)  a  large 
area  for  pointing  should  be  provided,  including  the  area  of  the  displayed  text  label,  plus  a 
half-character  distance  around  the  label. 

d)  When  cursor  positioning  is  the  sole  or  primary  means  of  data  entry  (as  in  menu 
selection),  a  direct  pointing  device  (e.g.,  a  light  pen)  should  be  used  in  preference  to  incremental 
stepping  or  slewing  controls  (e.g.,  keys  or  joystick). 

5. 2. 2. 3  Precise  positioning/pointing. 

a)  Where  precise  pointing  is  required,  as  in  graphics  generation,  a  point  designation  feature 
should  be  provided. 

b)  A  continuously  operable  control  (such  as  a  joystick  or  mouse)  should  be  used  to  control 
direct  pointing,  rather  than  discrete  controls  (e.g.,  cursor  control  keys). 

5. 2. 2. 4  Multiple  cursors. 

a)  Use  of  multiple  cursors  should  be  avoided  unless  indicated  by  usei  task  requirements. 

b)  Where  multiple  cursors  are  used,  they  should  be  visually  distinctive. 

c)  An  indication  of  cursors  which  are  active  should  be  provided. 

d)  Where  separate  control  is  provided  for  multiple  cursors,  pointing/control  operations 
should  be  compatible. 

5.2.3  Text  entry. 

a)  Adequate  display  capacity  (number  of  lines  and  line  length)  should  be  provided  to  support 
text  entry  and  editing. 

b)  When  possible,  the  system  should  automatically  default  to  a  standard  text  input  format. 
When  users  can  define  tex  entry  formats,  they  should  be  capable  of  being  stored  for  future  use. 

c)  Frequently  used  text  segments  (for  example  distribution  lists)  should  be  separately 
stored  and  should  not  require  keying  when  needed. 


Data  entry  -  Text  entry 


d)  Information  required  for  text  entry  or  editing,  such  as  user  guidance  information,  should 
be  separately  displayed  on  the  display  medium,  and  should  be  distinct  from  entered  or  displayed 
text. 


e)  As  required  by  the  system  and  the  user  task,  auditory  signals  should  be  provided  to  alert 
the  user  to  direct  attention  to  the  display. 

5.2.3. 1  Cursor  movement. 

a;  When  entering  or  editing  text,  users  should  be  able  to  freely  move  the  cursor  within  a 
displayed  page,  to  specify  items  for  change,  and  to  make  changes  directly  to  the  text,  and  should  be 
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able  to  move  cursors  by  specific  units  of  text,  such  as  by  paragraph,  line,  page,  and  character. 

b)  Users  should  not  have  to  frequently  alter  hand  positions  between  a  pointing  device  (such  a 
joystick)  to  position  cursors  and  the  keyboard  to  edit  or  add  text. 

52.3.2  Editing. 

a)  Users  should  be  able  to  specify  units  of  text  in  editing  and  other  control  tasks;  e.g., 

"Delete- Word",  "Move-Paragraph",  and  "Print-Page". 

b)  Users  should  be  able  to  select  and  move  sections  of  text  within  a  document.  Text  specified 
for  control  entry,  e.g.,  "Delete-Paragraph"  should  be  highlighted  or  otherwise  indicated. 

c)  Easy  to  use  commands,  such  as  MOVE,  COPY,  and  DELETE,  for  adding,  inserting,  or 
deleting  text  segments  should  be  provided.  ROLL  and  SCROLL  commands  should  refer  to  the  display 
window  such  that  the  display  window  appears  as  an  aperture  moving  over  stationary  text, 

d)  Editing  actions  should  be  reversible,  by  use  of  an  UNDO  function. 

e)  All  explicit  action  should  be  required  to  delete  sections  of  text. 

5.2.3.3  Page  formatting. 

a)  Easy  means  for  users  to  specify  page  formats  (margins,  tabs,  etc.)  should  be  provided. 

b)  The  system  should  provide  automatic  line  breaks  when  entered  text  reaches  right 
margins.  Automatic  word-wrap  should  be  provided  (carriage  returns  should  not  occur  in  the 
middle  of  words). 

c)  Hyphenation  should  only  occur  by  user  specification. 

d)  Page  breaks  should  be  under  the  control  of  the  user:  for  example,  specifying  the  number 
of  lines  that  must  appear  in  a  paragraph  on  a  page. 

e)  Entered  text  should  be  left  justified,  and  consistent  spacing  provided  between  words, 
unless  otherwise  specified  by  the  user. 


Data  entry  -  Text  entry 


f)  Natural  units  of  text  should  be  provided,  e.  g.,  by  paragraphs,  pages,  and  report  sections. 

g)  Control  entries  which  are  displayed  in  text  (such  paragraph  indentation  symbols,  printer 
commands  such  as  begin  and  end  underline,  etc)  should  be  distinguishable  from  the  main  text. 

5. 2.3.3. 1  Pagination. 

a)  The  system  should  provide  automatic  pagination,  while  providing  the  user  the  capability 
to  specify  page  size. 

b)  If  automatic  repagination  is  not  provided,  a  warning  message  should  be  presented  to  the 
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c)  Users  should  be  able  to  override  automatic  pagination  and  be  able  to  specify  page 
numbers,  at  any  point  in  a  document. 

d)  The  system  should  automatically  increment  pages  at  any  point  after  the  user  specifies  a 
beginning  page  number. 

e)  Inserting  text  into  a  paginated  document  should  not  result  in  loss  of  information. 

5. 2.3.4  Searching  text. 

a)  Character  string  search  capability  should  be  provided  (e.g.,  FIND  'CASREP')  and  should 
automatically  locate  the  cursor  at  the  occurrence  of  any  matched  strings. 

b)  Upper  and  lower  case  should  be  ignored,  unless  specified  by  the  user. 


FIND  'Casrep'  FIND  ’CASRep'  FIND  'CasRep' 


"As  diseased  in 


CASREP 


t^^^ied  .  . ." 


Result  of 
search 


FIGURE  27.  Examples  of  case  insensitive  search  items. 


c)  A  global  search  and  replace  capability  should  be  provided.  For  example,  a  user  should  be 
able  to  command  the  system  to  locate  all  occurrences  of  the  string  "respond"  and  replace  all 
occurrences  with  the  string  "response". 

d)  Users  should  be  able  to  specify  upper  and  lowercase  matches  in  global  search  and  replace 
(e.g.,  REPLACE  'chief  with  'Chief  )  transactions. 


Data  entry  -  Text  entry 


5. 2.3. 5  Printing. 

a)  A  display  mode  sho,.'d  be  provided  which  displays  text  exactly  as  it  will  be  printed  (for 
example,  underlining,  accurate  line  and  page  breaks,  font  characteristics). 

b)  Printout  options  should  be  selectable  (spacing,  margins,  fonts,  etc)  as  well  as  portions  of 
text  to  be  printed. 

c)  The  status  of  selectable  printout  options  should  be  available  to  the  user  for  review  and 
change,  and  printout  status  information  should  be  displayed  for  the  user,  including  acknowledgment 
of  print  command,  print  queue  information  (for  shared  printers),  and  printer  information  (for 
example,  printer  on-off  line,  paper  supply,  printer  location,  form  location). 

5.2.4  Form  entry. 

5.2.4. 1  Format. 
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a)  A  unique,  standard  symbol  (such  as  an  ">"  or  code  (such  as  inverse  video)  should  be  used 
for  prompting  data  entry. 

b)  Hardcopy  forms  that  are  used  for  inputting,  updating,  or  correcting  data  should 
correspond  to  screen  display  in  terms  of  order  of  entry,  data  grouping,  etc. 

c)  Where  no  source  documents  or  forms  exist  to  support  data  entry,  data  fields  should  be 
logically  grouped,  by  sequence  and  frequency  of  use,  importance,  and  functional  associations. 

d)  When  entry  of  data  in  a  field  is  deferred  or  omitted,  the  system  should  identify  the  field 
by  highlighting  or  other  means  and  the  user  should  be  informed  that  data  have  not  been  input. 

5.2.4. 1.1  Field  definition/delimiters. 

a)  Separate  data  items  should  be  entered  without  the  need  for  user  input  of  separators  or 
delimiters.  If  a  user  input  field  delimiter  is  needed,  a  standard  symbol,  such  as  a  slash  (/)  should 
be  used. 


Delimiters  required 


060587 


87t05|06 


6.5.87 


BETTER 


25/5/83 


25-12-87 


3:2:52 


Tieio  aeiimit 


Delimiters  not  required 
Day:  |  | 

Month:  □ 

I  I 

FIGURE  28.  E 
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b)  Special  characters  (such  as  underlining,  data  field  "boxing")  should  be  used  to  delineate 
data  fields  and  data  field  lengths. 

c)  Data  entry  by  overwriting  a  set  of  characters  within  a  field  should  be  avoided, 
deletion/insertion  should  be  used  instead. 

d)  Users  should  not  have  to  remove  unused  underscores  or  otherwise  enter  keystrokes  for 
each  position  within  a  variable  length  entry  area. 

e)  Optional  vs.  required  data  entries  within  fields  on  input  forms  should  be  distinct. 
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FIGURE  29.  Examples  of  data  field  coding 


5.2.4. 1.2  Data  fieid/iabeling. 

a)  Data  fields  should  be  labeled  consistently,  uniquely  and  adjacent  to  the  data  input  area. 
Labels  for  data  fields  should  be  visually  distinctive,  (by  color,  size,  font,  etc.)  from  data  fields, 
prompts,  and  other  information  of  displays. 

b)  Formats  should  be  consistent  (e.g.,  by  special  relation  to  associated  data  field,  color, 
fonts,  size,  location). 

c)  Data  field  labels  should  appear  in  upper  case  only,  while  entered  text  may  appear  in  both 
upper  and  lower  case. 

d)  Unless  required  for  user  form  design,  field  labels  should  not  be  editable  by  users. 

e)  Field  labels  should  terminate  with  a  special  symbol  (e.g.,  a  colon)  to  signify  data  entry 

point. 


f)  Data  fields  should  be  descriptively  worded  by  whole  words  (preferred)  or  predefined 
terms,  codes,  or  abbreviations  (acceptable). 

g)  Arbitrary  codes,  such  as  numbering  schemes,  should  be  avoided. 


Data  entry  -  Form  entry  -  Format 


5. 2. 4. 1.2.1  Units  of  measurement. 

a)  When  units  of  measurement  are  consistent  within  a  field  entry,  field  labels  should 
identify  the  appropriate  units. 

b)  Units  of  measurement  familiar  to  the  user  should  be  used. 

c)  Where  alternative  units  of  measurement  may  be  required  for  input,  an  associated  field  or 
field  modifier  should  be  provided. 

d)  The  user  should  not  have  to  transform  units  at  time  of  data  entry. 


Lbs  X  1000 

Metric  tons 

Long  Tons 

input  Aircraft  Weight: 

23 

Accept  input  as  23  Metric  tons?  (Y  or  N):| 

FIGURE  30.  Alternate  means  to  input  units  sensitive  data 


5.2. 4. 2  Cursor  positioning. 
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a)  When  a  new  or  blank  form  is  presented  to  the  user,  the  cursor  should  be  positioned  at  the 
beginning  of  the  first  entry  field. 

b)  User  cursor  positioning  should  be  minimized. 

c)  Where  the  number  of  fields  is  limited,  screen  traversal  distances  are  short,  and  when 
data  fields  will  be  accessed  sequentially,  explicit  tabbing  (using  TAB  or  cursor  control  keys)  should 
be  available  for  advancing  to  subsequent  fields. 

d)  In  complicated  forms  with  many  fields,  or  when  field  entry  will  be  less  predictable  (as  in 
data  base  ufxfate),  direct  pointing  devices,  such  as  mouse  or  lightpen,  should  be  available  for 
selecting  fields. 

e)  The  user  should  not  be  able  to  position  the  cursor  within  protected  fields  (fields  may  be 
protected  as  a  function  of  level  of  authorization,  or  reserved  for  display  of  computed  values,  etc.). 

5.2.4.3  Data  entry/editing. 

a)  When  entering  logically  related  items  (e.g.,  personnel  information  sorted  by  state  of 
residence  and  last  name),  the  system  should  only  require  entry  of  information  which  changes 
through  subsequent  forms,  and  this  information  should  be  located  at  the  end  of  the  form  filling 
transaction. 

Data  entry  -  Form  entry  -  Format 


b)  Users  should  be  able  to  REVIEW,  CANCEL,  or  BACKUP  to  any  field  and  change  any  item 
prior  to  taking  a  final  ENTER  action. 

c)  For  variable  length  field  entries,  automatic  justification  of  the  input  data  should  be 
provided. 

d)  Unless  otherwise  required  by  processing  or  display  requirements,  alphanumeric  input 
should  be  left  justified,  and  numeric  input  should  be  right  justified  for  integer  data  or  decimal 
point  justified  for  decimal  data. 

e)  Users  should  not  have  to  provide  a  keystroke  for  every  character  space  reserved  by  the 

field. 

5.2.5  Tabular  data  entry. 

a)  Where  sets  of  data  must  be  entered  sequentially  or  where  data  is  keyed  row  by  row,  a 
tabular  display  format  should  be  used. 

b)  Information  input  should  be  automatically  justified,  without  the  user  having  to  insert 
blank'null  characters. 

c)  Numeric  data  should  be  automatically  right,  or  decimal  point,  justified. 


d)  Users  should  not  have  to  input  leading  or  trailing  zeros. 
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POOR 

BETTER 

10234100. 

102341.0 

5461 .0030 

5461  .003 

002.70000 

2.7 

i _ 

FIGURE  31.  Examples  of  poor  and  better  numeric  justification 


e)  Numeric  values  should  be  displayed  to  level  of  significance  required  of  the  data  regardless 
of  the  value  of  individual  input  data. 

f)  Every  fifth  row  of  a  table  should  be  separated  by  a  blank  line  or  other  delimiter. 

5.2.5. 1  Cursor  positionina/tabbing.  Users  should  be  able  to  tab  to  adjacent  fields,  across  rows  or 
columns. 

Data  entry  -  Tabular  data  entry 


5.2.5.2  Labels. 

a)  Each  row  and  column  should  be  uniquely  and  informatively  labeled  and  should  be  visually 
distinct  from  data  entries. 

b)  Where  more  data  fields  exist  than  can  be  displayed  on  a  single  display  page,  row  and 
column  labels  should  remain  along  the  top  (or  bottom)  and  left  (or  right)  edges  of  the  display. 

c)  Labels  should  not  scroll  off  the  visible  portion  of  the  display. 

5.2.6  Qraph.ic.S.£riiry. 

a)  When  entering  and  manipulating  graphic  data,  pointing  devices  (such  as  mouse, 
trackball)  should  be  used  rather  than  keyboards.  When  pointing  is  used  as  medium  for  graphic 
input  and  manipulation,  system  control  should  also  use  pointing  devices. 

b)  Easy  means  for  saving  and  loading  graphic  displays  should  be  provided.  Users  should  be 
able  to  specify  graphic  display  names  and  to  review  file  catalogs  of  stored  graphics. 

c)  When  specified  by  the  user,  the  system  should  provide  automatic  object  alignment  to  an 
invisible  rule  or  grid  structure.  The  user  should  not  have  to  align  and  space  separate  "objects". 

d)  Where  possible,  the  system  should  validate  graphic  data  input.  For  example,  when  a  user 
attempts  to  fill  the  same  graphic  space  with  more  than  one  object. 

5.2.6. 1  Cursors/DQinter  positioning. 

a)  Graphics  display  cursors  should  be  distinctive  and  should  have  a  point  which  can  be  used 
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to  select/manipulale  small  graphic  objects. 

b)  Cursors  should  be  easy  to  position  and  simple  to  point  to  display  elements  or  locations. 


Pointing  cursors  too  vague  or  obscuring 

More  precise  pointing  possible 


FIGURE  32.  Obscure  and  precise  graphic  cursors. 


Data  entry  -  Graphics  entry 


c)  Graphic  data  entry  cursors  should  have  a  movement  (pointing)  component  and  an 
activation  component:  the  movement  component  should  position  the  cursor  while  the  activation 
component  should  activate  the  cursor  pointing  location  in  order  to  manipulate  a  display  element  (as 
examples,  selecting  an  object  to  be  moved,  drawing  a  line,  and  selecting  a  menu  option). 

5.2.6. 2  Drawing. 

a)  Automatic  grid  alignment  for  drawn  objects  should  be  available  to  users  at  their  request. 
Users  should  be  able  to  specify  grid  intervals. 

b)  Users  should  be  able  to  scale  object  sizes,  by  enlarging  or  reducing. 

c)  Users  should  be  able  to  fill  enclosed  areas  with  colors  or  patterns. 


FIGURE  33.  Example  of  fill  palette  options 


d)  Users  should  be  able  to  select  automatic  figure  completion  (e.g.,  automatic  closure  of 
polygons). 

e)  Where  possible,  general  computer  models  that  will  allow  users  to  generate  specific  from 
general  drawings  should  be  provided. 

f)  Critical  or  difficult  graphic  drawing  tasks  should  be  supported  by  a  "zooming"  function  to 
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enlarge  critical  display  areas.  An  example  of  a  zoom  function  is  presented  in  figure  34. 

5. 2. 6. 2.1  Figure  generation. 

a)  The  system  should  automatically  draw  lines  between  user  specified  points  and  should 
support  the  drawing  of  rectangles,  arcs,  avals  and  other  figures. 

b)  Objects  should  emerge  as  they  are  being  drawn.  For  example,  when  a  user  draws  a  line 
by  moving  a  pen  across  a  graphics  tablet,  ’he  line  displayed  should  emerge  as  the  pen  moves  from 
the  start  point,  increasing  or  decreasing  in  length  and  slope,  as  the  pen  moves  across  and  around  the 
tablet.  Figure  35  presents  this  concept. 

c)  Users  should  bo  able  to  constrain  line  drawing  to  exactly  vertical  or  horizontal.  For 
precise  drawing,  users  should  be  able  to  specify  their  geometric  relations  to  other  lines  (e.g., 
parallel  or  perpendicular  to  another  line). 


Data  entry  -  Graphics  entry 


FIGURE  34.  Zoom  function. 
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e)  Users  should  be  able  to  copy  (duplicate),  rotate,  and  vertically  or  horizo.nial!/  mir''or 
image  objects. 

5. 2. 6. 2. 2  Grouping/merqing  objects. 

a)  The  svstem  should  automatically  merge  objects  and  assign  precedence  to  objects.  For 
e:  ^mple,  for  two  icons  or  symbols  which  are  somewhat  superimposed,  the  system  would  obscure 
part  of  the  partially  covered  symbol.  An  example  of  this  is  presented  in  figure  37. 
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FIGURE  3/.  Establishment  of  graphic  object  precedence 
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b)  The  system  should  provide  means  to  group  separate  objects  into  a  single,  grouped  object 
(so  that  separate  objects  may,  for  example,  be  moved  as  a  unit,  or  so  that  a  complex  object  can  be 
incromenta'Iy  drawn). 

c)  Where  separately  drawn  lines  must  connect  at  terminal  points,  the  system  should 
automatically  make  the  connections. 

5. 2. 6. 3  Graphic  objects,  elements  and  attributes. 

a)  Graphic  display  elements  (e.g.,  color,  line  thickness,  text  fonts)  should  be  selectable  by 
the  user  for  manipulation,  and  element  attributes  (e.g.,  blue.  1/64  inch  line  thickness,  12  point 
Lincoln-Mitre  font)  should  be  selectable  and  editable  by  pointing  to  and  selecting  from  displayed 

examples. 

b)  Object  attributes  should  be  displayed  as  selected  (using  selected  colors,  textures,  font 
sice  shape,  etc),  and  should  not  be  appended  to  objects  by  codes  or  other  means. 

c;  Attribute  solection/editing  methods  should  be  consistent. 

d)  Artivatod/selected  graphic  elements  should  be  tiighlighted  or  otherwise  indicated  to  the 

lise-r. 
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e)  ijsr.r  selectable  objects  should  be  easily  rripositioned,  duplicated,  or  deleted. 
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5. 2. 6. 4  Plotting  data. 

a)  When  complex  graphic  data  must  be  entered  quickly,  computer  aids  should  be  provided. 
For  example,  when  plotting  data  within  Cartesian  coordinates,  the  system  should  automatically 
draw  lines  between  the  specified  points  of  a  function. 
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(Actual  colors  would  be  displayed) 

FIGURE  38.  Example  of  graphic  figure  attributes  and  elements  selection  option. 


b)  The  system/software  should  support  automatic  plotting  of  stored  data. 

c)  Where  frequently  used  or  constrained  graphic  formats  exist,  the  system  should  provide 
graphic  templates  to  the  user. 

d)  The  system  should  provide  for  automatic  scaling  of  graphic  data  and  users  should  be  able 
to  modify  system  generated  scales. 

e)  When  graphic  data  can  be  derived  from  data  already  in  the  computer,  machine  aids  should 
be  provided.  For  example,  automatic  curve  smoothing,  reshaping  polygons,  data  filtering,  etc. 

5.2.7  Data  validation. 

5.2.7. 1  User  validation. 

a)  The  user  should  be  able  to  obtain  a  paper  copy  (virtual  screen  dump)  of  the  contents  of 
alphanumeric  or  graphic  displays. 

b)  If  information  is  printed  remotely,  print  status  messages  should  be  displayed  and  screen 
contents  should  not  be  changed  as  a  result  of  the  print  operation. 

c)  In  repetitive  data  entry  task,  inputs  should  be  validated  at  the  time  of  each  transaction. 
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d)  For  novice  users,  the  system  should  provide  optional  item-by-item  data  validation 
within  a  multiple-entry  transaction  (e.g.,  at  the  end  of  every  data  field  entry). 

5.2.7.2  System  validation. 

a)  Where  possible,  automatic  data  validation  to  check  data  for  correct  format  should  be 
provided.  For  example,  a  date  is  entered  as  "February  31",  should  generate  an  error  message. 

b)  Correct  data  entries  should  always  be  accepted  and  processed  properly  by  the  computer 
without  need  for  user  involvement  to  proceed. 

c)  Where  possible,  when  a  data  or  command  entry  does  not  meet  validation  logic,  a 
cautionary  message  should  be  displayed  asking  the  user  to  confirm  data  entry. 

d)  If  data  validation  detects  a  probable  error,  an  error  message  should  be  displayed  at  the 
completion  of  a  field/data  entry,  without  interrupting  an  ongoing  transaction. 
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5.3  Data  display. 

5.3.1  General. 

5. 3. 1.1  Displa\/  of  information. 

a)  Information  density  should  be  minimized  in  displays  used  for  critical  task  sequences.  For 
critical  information,  a  minimum  of  one  character  space  should  be  left  blank  vertically  above  and 
below  critical  information,  with  a  minimum  of  two  character  spaces  left  blank  horizontally  before 
and  after. 

b)  Whenever  possible,  users  should  be  able  to  see  the  whole  page  (e.g.,  of  text,  tactical  map, 
etc.)  with  which  they  are  working. 

c)  Data  needed  for  a  transaction  should  be  displayed  in  a  directly  usable  form,  and  only 
essential  data  should  be  displayed. 

d)  Users  should  be  able  to  control  the  amount,  format,  and  complexity  of  displayed  data,  as 
necessary  to  meet  task  requirements. 

e)  Users  should  be  able  to  obtain  a  paper  copy  of  the  exact  contents  of  alphanumeric  or 
digital  graphic  display  in  systems  where  mass  storage  is  limited,  mass  stored  data  can  be  lost  by 
power  interruption,  or  where  record  keeping  is  required. 

f)  When  task  performance  requires  or  implies  the  need  to  assess  currency  of  information, 
displays  should  be  annotated  with  date-iime  information. 

5.3. 1.2  Consistency/standardizatior. . 

a)  Data  should  be  displayed  consisfenfiy  in  word  choice,  format,  and  basic  style^  and  within 
standards  and  conventions  familiar  to  users. 

b)  Data  display  should  be  standardized  within  applications  and  across  transactions. 

5.3. 1.3  Wording/stvle. 

a;  The  wording  of  displayed  data  and  labels  should  incorporate  familiar  terms  and  the 
task  oriented  language  of  the  users,  and  use  of  unfamiliar  lang"3ge  of  designers  and  programmers 
should  be  avoided. 

b)  Consistent  wording  should  be  provided  foi  displays,  data  and  labels;  e.g.,  the  word 
'Screen"  should  not  be  used  to  mean  "Display  Frame"  in  one  place,  and  "Menu  Options"  in  another 

c)  Consistent  grammatical  structure  for  data  and  labels  within  and  across  displays  should  be 
provided. 
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5.3. 1.4  Lai3£infl. 

a)  Each  individual  data  group,  message,  or  frame  should  contain  a  distinct,  unique,  and 
descriptive  label. 

b)  Display  frame  labels  should  be  an  alphanumeric  code,  or  an  abbreviation  which  is 
prominently  displayed  and  is  short  enough  (3-7  characters)  or  meaningful  enough  to  be  learned 
and  remembered  easily. 

c)  Labels  should  be  highlighted  or  otherwise  emphasized.  The  technique  used  should  be 
easily  distinguished  from  that  used  to  highlight  or  code  emergency  or  critical  messages. 

d)  Labels  should  be  descriptively,  consistently  and  distinctly  worded. 

e)  Label  locations  and  formats  should  be  consistent. 

5.3. 1.5  Format. 

a)  A  consistent  organization  of  display  features  among  displays  should  be  adopted. 

b)  Different  elements  of  display  formats  should  be  distinctive  within  a  display,  but  should 
be  consistent  across  displays. 

c)  Blank  space  should  be  used  to  structure  a  display. 

d)  Groups  of  information  should  be  separated  by  blanks,  lines,  color  coding,  or  other 
visually  distinctive  means. 

5.3. 1.5.1  Uygg.t. 

a;  Display  windows  should  be  labeled  at  the  top  with  a  title  or  header  which  describes  the 
contents  or  purpose  of  the  display. 

b)  At  least  one  blank  line  between  the  title  and  the  body  of  the  display  should  be  provided. 

c)  Where  control  is  exerted  via  keyboard,  the  last  several  lines  at  the  bottom  of  every 
display  should  be  reserved  for  status  and  error  messages,  prompts,  or  command  entry. 

d)  Whp''e  users  must  analyze  sets  of  data  to  discern  similarities,  differences,  trends,  and 
relationships,  displays  should  be  formatted  so  that  the  data  are  grouped  to  facilitate  analysis  and 
comparison, 

e)  Data  fields  to  be  compared  on  a  character  by  character  basis  should  be  positioned  one 
above  the  other. 
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FIGURE  39.  Example  of  data  layout  which  facilitates  data  comparison. 


f)  Where  possible,  data  should  be  grouped  by  sequence,  function,  importance,  or  frequency 
of  use,  or  by  other  means  such  as  alphabetic  or  chronology. 

g)  Context  for  displayed  data  should  be  provided. 

h)  Visually  distinctive  data  fields  should  be  provided. 

5.3. 1.5.2  Multipaae  displays. 


a)  When  a  display  contains  too  much  data  for  presentation  in  a  single  frame,  the  data  should 
be  partitioned  into  separately  displayable  pages. 


b)  Related  data  should  appear  on  the  same  page  and  relations  among  data  sets  should  appear 
in  an  integrated  display  rather  than  partitioned  into  separate  windows. 


c)  Each  page  shouU  be  labeled  to  show  its  relation  to  the  others. 


5. 3. 1.6  Coding. 


a)  Coding  should  be  employed  to  differentiate  between  items  of  information,  to  call  the  user's 
attention  to  changes  in  the  stale  of  the  system,  and  to  indie  3  important,  hazardous,  or  critical 
information  which  requires  user  action. 


b)  Coding  by  data  category  should  be  provided  where  a  user  must  distinguish  rapidly  among 
different  categories  of  displayed  data  that  are  distributed  in  an  irregular  way  on  the  display. 

c)  Meaningful  codes  should  be  used  rather  than  arbitrary  codes.  For  example,  use  "M"  for 
male  and  "F"  for  female  rather  than  T  and  "2". 

d)  Coding  should  be  consistent  across  displays.  Codes  assigned  special  meaning  in  a  display 
should  be  defined  at  the  bottom  of  the  display  and  should  replicate  the  code  being  defined. 


5.3. 1.6.1  Alphanumeric  coding. 


a)  Alphanumeric  coding  may  be  used  to  supplement  other  coding  schemes  ,  but  should  not  be 
used  as  the  sole  means  to  call  attention  to  important  or  critical  information. 
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b)  Alphanumeric  codes  should  display  all  letters  consistently  in  either  upper  or  lower  case. 

c)  When  short  alphanumeric  codes  combine  both  letters  and  numbers,  letters  and  numbers 
should  be  grouped  together  rather  than  interspersing  letters  with  numbers:  for  example; 
letter-letter-number  ("HWS")  will  be  read  and  remembered  more  accurately  than  will 
letter-number-letter  ("H5W"). 

d)  Arbitrary  alphanumeric  codes  that  must  be  recalled  by  the  user  should  be  no  longer  than 
four  or  five  characters. 

5.3.1 .6.2  Auditory  coding. 

a)  Auditory  coding  signals  should  be  used  to  alert  an  operator  to  critical  conditions  or 
operations,  as  a  means  of  supplementing  visual  display  or  as  an  alternative  means  of  information 
presentation  where  visual  display  is  not  feasible,  and  as  a  means  to  provide  feedback  for  control 
actuation,  data  entry,  or  completion  of  timing  cycles  and  sequences. 

b)  Noncritical  auditory  signals  should  be  capable  of  being  turned  off  at  the  discretion  of  the 
user.  A  simple,  consistent  means  of  acknowledging  and  turning  off  alarm  signals  should  be 
provided. 

c)  Auditory  signals  should  be  provided  when  computer  response  to  a  user  request  is  greater 
than  15  seconds. 

d)  Signals  should  be  intermittent  in  nature  to  allow  the  user  sufficient  time  to  respond. 
Auditory  signals  should  be  distinctive  in  intensity  and  pitch. 

e)  The  number  of  signals  to  be  identified  should  not  exceed  four. 

f)  The  intensity,  duration,  and  source  location  of  the  signal  should  be  selected  to  be 
compatible  with  the  acoustical  environment  of  the  intended  receiver  as  well  as  with  the 
requirements  of  other  personnel  in  the  signal  area. 

g)  For  auditory  displays  with  voice  output,  different  voices  should  be  used  to  distinguish 
different  categories  of  data. 

h)  If  computer-generated  speech  output  is  used  for  auditory  display,  a  special  alerting 
signal  should  be  provided  to  distinguish  them  from  routine  voice  messages. 

a)  Brightness  intensity  coding  may  be  used  to  differentiate  between  adjacent  items  of 
information  or  to  code  two  to  three  state  conditions.  Brightness  coding  should  have  only  one  meaning 
(e  g.,  ON-OFF  or  FAST-SLOW,  or  STANDBY-RUN,  but  not  all  three). 

b)  Each  level  of  brightness  coding  should  be  separated  from  the  next  nearest  level  by  a  2:1 
ratio  and  should  discriminate  only  between  two  categories:  bright  and  dim. 
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c)  "Inverse  video"  may  be  used  to  highlight  critical  items  that  require  user  attention.  When 
used,  brightness  inversion  should  be  reserved  exclusively  for  that  purpose  and  not  used  for  general 
highlighting. 


Inverse  video  to  code  important  information 


VS.  normal  video  which  does  not  stand  out 


FIGURE  40.  Coding  by  inverse  and  normal  video. 


5.3. 1.6.4  Color  coding. 

a)  Color  coding,  where  appropriate,  should  be  used  to  differentiate  between  classes  of 
information  in  complex,  dense,  and  critical  displays. 

b)  The  following  reserved  color  meanings  should  be  used; 

RED  should  be  used  to  indicate  conditions  such  as  "no-go",  "error",  "failure", 
"malfunction",  etc. 

FLASHING  RED  should  be  used  only  to  denote  emergency  conditions  requiring 
immediate  operator  action,  or  to  avert  personnel  injury,  equipment  damage,  or 
both. 

YELLOW  should  be  used  to  indicate  marginal  conditions  or  to  alert  situations  where 
caution,  recheck,  or  unexpected  delay  is  necessary. 

GREEN  should  be  used  to  indicate  that  monitored  equipment/processes  are  within 
tolerance  or  a  condition  is  satisfactory  and  that  it  is  all  right  to  proceed  with  an 
operation  or  transaction. 

WHITE  should  be  used  to  indicate  system  conditions  that  do  not  have  operability  or 
safety  implications,  but  indicate  alternative  functions  (e.g.,  "Printer  #2 
on-line"). 

BLUE  nay  be  used  as  an  advisory  color,  preferential  use  of  blue  should  be  avoided. 

c)  Color  may  be  used  to  identify  data  categories  when  it  does  not  conflict  with  other  color 
coding  conventions  and  does  not  conflict  with  the  color  associations  specified  above.  Use  of  cole  as  a 
formatting  code  should  be  subordinate  to  other  methods. 

d)  Color  coding  should  be  redundant  to  some  other  means  of  coding  such  as  symbotogy;  coding 
only  by  color  should  be  avoided. 
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e)  Color  coding  should  not  be  used  if  the  information  will  be  accessed  from  monocromatic 
displays  or  hardcopy  printouts,  or  if  users  may  be  deficient  in  color  perception. 

f)  Colors  should  be  easily  discriminable  and  color  coding  should  be  used  conservatively. 

Each  color  should  represent  only  one  category  of  displayed  data. 

g)  Brighter  or  more  saturated  colors  should  be  used  when  it  is  necessary  to  draw  a  users 
attention  to  critical  data. 

5.3.1 .6.5  Flash  coding. 

a)  Flash  coding  should  only  be  used  to  display  an  urgent  need  for  user  attention. 

b)  No  more  than  two  levels  of  flash  coding  should  be  used.  Flash  rate  in  the  range  of  3  to  5 
Hz  should  be  used  with  equal  "on"  and  "off  intervals.  If  two  flash  coding  levels  are  used,  the  second 
should  flash  at  less  than  2  Hz. 

c)  When  a  displayed  item  is  blink  coded,  a  flashing  marker  symbol  (such  as  an  asterisks) 
should  be  used  rather  than  blinking  the  item  itself. 

d)  Event  acknowledgment  or  flash  suppression  keys  should  be  provided. 

5. 3. 1.6.6  Line  coding. 

a)  Line  coding  by  color,  including  variation  in  line  type  (e.g.,  solid,  dashed,  dotted)  and  line 
width  ("boldness")  should  be  used.  An  example  of  line  coding  is  presented  in  figure  41 . 

b)  Underlining  may  be  used  to  indicate  unusual  values,  errors  in  entry,  and  data  changes. 
Underlining  rather  than  overlining  should  be  used. 

c)  Coding  by  line  length  should  be  used  for  applications  involving  spatial  categorization  in  a 
single  dimension  (e.g.,  velocity,  acceleration  vectors). 

d)  Coding  by  line  direction  should  be  used  for  applications  involving  spatial  categorization  in 
two  dimensions,  (e.g.,  target  bearing). 

5.3.1 .6.7  Pattern/location  coding.  Pattern  and  location  coding  may  be  used  to  reduce  search  time 
by  restricting  the  area  to  be  searched  to  prescribed  segments. 

5.3. 1.6.8  Shape/svmbol  coding. 

a)  Symbol  coding  should  be  used  to  enhance  the  transfer  of  information. 

b)  Symbols  should  be  analogs  of  the  event  or  system  elements  they  represent,  be  in  general 
use  and  well-known  to  the  users,  and  be  based  on  established  standards  or  conventional  meanings. 
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FIGURE  41.  Example  of  line  coding 


c)  Symbol  heights  should  not  differ  more  than  three  sizes. 

d)  Special  symbols,  such  as  asterisks,  arrows,  etc.,  may  be  used  to  draw  attention  to 
selected  items  in  alphanumeric  displays. 

e)  Use  of  special  symbols  should  be  consistent  and  their  meanings  unique. 

f)  Shape  codes  using  more  than  15  different  shapes  should  be  avoided  Component  shapes 
may  be  used  in  combination  (for  example,  symbol  modifiers  such  as  velocity  direction  vectors). 
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5.3. 1.6. 3  Size  coding.  When  used,  size  coding  should  not  exceed  3  sizes.  For  size  coding,  a  larger 
symbol  should  be  at  least  1 .5  times  the  height  of  the  next  smaller  symbol. 
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discrimination 
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more  than  three  levels  of 
size  coding  is  easy.  Recognition  of  more  than 
three  sizes,  without  benefit  of  comparisons,  is  difficult 


FIGURE  42.  Three  easily  recognizable  sizes 


5.3.2  Display  control. 

a)  Users  should  be  able  to  tailor  information  displays  by  controlling  data;  selection, 
coverage,  updating,  and  suppression,  and  should  be  able  to  specify  data  for  display.  An  easy  means 
to  return  to  normal  display  coverage  should  be  provided. 

b)  Users  should  be  able  to  control  displayed  data  or  enter  new  data  when  required  by  a  task. 

c)  .As  required,  users  should  be  able  to  print  paper  copies  of  information  displayed. 

d)  Users  should  not  be  required  to  remember  data  accurately  from  one  display  page  to 
another. 

5.3.2. 1  Display  of  control  options. 

a)  Screen  control  locations  and  control  options  should  be  clearly  and  appropriately 
indicated. 

b)  When  a  user  is  prompted  by  the  system  for  a  parameter  with  a  predefined  fault,  the 
default  value  should  be  shown. 

c)  Information  that  the  user  must  have  to  manipulate  displays  should  be  displayed  as  the 
control  becomes  available. 

5.3.2.2  Pata-acce^iQ-n. 

a)  A  consistent  and  easy  means  of  moving  through  data  should  be  provided  by  windowing, 
panning,  paging  or  scrolling. 

Data  display  -  Display  control 
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d)  Paging  vs.  scrolling  labels  should  be  consistently  distinct  and  unambiguous;  e.g.,  UP  may 
be  used  to  scroll  up  a  line  within  a  frame  and  PREVIOUS  to  go  to  a  preceding  page. 

e)  Labeling  for  display  paging  should  be  referred  to  in  functional  terms;  (e.g.,  FORWARD 
and  BACK,  or  NEXT  and  PREVIOUS). 

f)  When  lists  of  numbered  items  exceed  one  display  page,  items  should  be  numbered 
continuously  in  relation  to  the  first  item  on  the  first  page. 

5. 3.2.4  Display  regeneration/data  update. 

a)  Where  users  must  accurately  read  changing  data  (e.g.,  target  range,  bearii.c,  speed),  the 
data  should  be  displayed  long  enough  to  read  to  the  level  of  precision  required. 

b)  Rate  of  display  regeneration  should  not  exceed  user  perceptual  and  information 
processing  capabilities. 

c)  Changing  alphanumeric  data  which  must  be  reliably  or  accurately  read  should  ric*  be 
updated  more  often  than  once  per  second. 

d)  When  the  information  displayed  is  to  be  considered  real  time,  changing  values  which  are 
used  to  identify  rate  of  change  or  tc  read  gross  values  should  not  be  updated  faster  than  5  times  per 
second,  nor  slower  than  2  times  per  second. 

5. 3. 2. 4.1  User/svstem  control. 

a)  Unless  directed  by  task,  system,  or  mission  requirements  (as  in  'actical  displays),  users 
should  be  able  to  initiate  display  regeneration  (e.g.,  "Redraw  Now",  or  "Recom  'ute  Now"). 

b)  The  rate  of  information  update  should  be  controllable  by  the  user  anq  should  be 
determined  by  the  use  to  be  made  of  the  data. 

c)  When  data  is  changed  via  automatic  processing  (as  in  real  time  sensor  data  processing  and 
display),  data  updates  should  be  temporarily  highlighted  orothenwise  marked. 

5. 3. 2. 4. 2  Freeze  frame. 

a)  When  displayed  data  are  automatically  updated,  users  should  be  able  to  "freeze"  the 
display  to  examine  changed  data  more  deliberately. 

b)  When  frozen,  the  display  should  clearly  be  labeled,  and  users  should  be  warned  if  some 
significant  data  change  has  occurred  due  to  .subsequent  processing  or  sensing  (as  in  radar  sweep 
updates). 

c)  When  resuming  update  after  display  freeze,  display  update  should  resume  at  the  current 
real-time  point  unless  otherwise  specified  by  the  us?*' 
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5. 3. 2.4. 3  Data  extrapolation.  When  needed,  a  prediction  display  extrapolating  dynamic  display 
information  should  be  provided;  for  example,  distribution  of  air  forces  in  10  minutes  given 
current  bearing,  velocity,  acceleration,  etc. 

5.3.3  Voice  displays.  Voice  displays  may  be  used  to  supplement  visual  displays  when 
communication  flexibility  is  necessary,  when  coded  signal  meanings  are  numerous  or  may  be 
forgotten,  for  presentation  of  complex  directions  or  instructions,  when  ambient  noise  may  mask 
simple  tonal  signals  or  in  conjunction  with  tonal  signals,  and  for  presentation  of  continuous 
information  where  rate  of  change  is  low. 

5.3.3. 1  Word  selection. 

a)  Words  selected  should  be  appropriate  to  the  task/information  presented,  concise,  and 
intelligible. 

b)  Whe.re  possible,  words  that  rhyme  and  may  confuse  message  interpretation  should  not  be 
part  of  the  spoken  lexicon,  or  should  not  be  presented  within  the  same  message. 

c)  Use  of  slang  should  be  avoided. 

d)  Words  vhth  more  than  one  syllable  should  be  used. 

e)  Alphanumeric  data  should  be  presented  using  phonetic  alphabets,  e.g.,  "Whiskey  Zebra 
three  two  seven"  should  be  used  in  preference  to  “WZ327"  where  the  "Z"  and  “3"  are  too 
phonetically  similar. 

5. 3.3. 2  Presentation. 

a)  Spoken  messages  should  be  produced  in  the  form  of  the  "average  talker",  in  an  American 
English  accent  without  regional  dialects. 

b)  Speech  intensity  should  be  appropriate  to  the  expected  ambient  noise  environment. 

Within  a  typical  office  space  intensity  should  be  approximately  70  to  75  dB  sound  pressure  level. 
Signal  to  noise  ratios  should  be  at  least  5:1 .  Audio  signal  power  should  be  approximately  300 
milliwatts  at  the  listeners  ear.  Speech  signals  should  fall  within  the  range  of  200  to  6100  Hz. 

c)  Spoken  warning  messages  should  be  preceded  by  an  alerting  signal.  Users  should  be 

required  to  acknowledge  spoken  warning  signals. 

d)  Mei'ca.qos  should  be  brief,  informative,  and  to  the  point. 

5.3.4  WindowS- 

a)  V^tRdow  overlays  may  be  provided  to  temporarily  add  data  (such  as  help  screens,  menus, 
or  ottier  featufior)  'o  a  display,  or  as  a  means  to  control  or  display  divergent  information,  or  to 
segregate  and  control  separate  operations. 

Data  display  -  Display  control 
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b)  The  display  screen  should  be  capable  of  displaying  each  of  the  windows  simultaneously,  in 
either  a  tiled  or  overlapped  format,  as  requested  by  the  user. 


FIGURE  44.  Example  of  tiled  vs.  overlapped  windows. 


c)  Windows  should  be  predefined  and  displayed  under  user  control,  as  appropriate  (e.g., 
user  acknowledgment  of  an  alert  window,  help  screen  calls,  etc.). 

d)  Window  overlays  should  be  nondestructive  and  should  not  permanently  erase  overlayed 
data.  See  figure  45. 

5. 3.4.1  Format. 

a)  Default  formats  should  represent  the  "configuration"  of  the  information  to  be  displayed 
(i.e.,  whether  the  information  conforms  to  the  standard  tile  format),  and  the  expectations  and 
experience  of  the  typical  user. 


Data  display  -  Windows 
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FIGURE  45.  Example  of  a  window  overlay. 


b)  The  size  and  shape  of  the  initial  presentation  of  a  window  should  be  consistent  with  its 
contents  (amount  of  information,  number  of  menus,  data  fields,  etc.). 

c)  Windows  which  are  dedicated  to  command  entry  by  keyboard  input  should  be  located  at  the 
bottom  of  the  display  area. 

5.3.4.2  Labeling  and  identification. 

a)  Windows  must  be  visually  separated  from  each  other  and  from  their  background, 
preferably  by  borders  or  similar  demarcation. 

b)  Windows  should  be  identified  by  a  label  consistently  located  at  the  top  of  the  window's 
border.  Where  several  windows  can  be  displayed  at  one  time,  active  windows  should  be  indicated  by 
labeling  or  other  means,  and  an  easy  means  of  shifting  among  windows  should  be  provided. 

c)  Labels  should  :z~,a\r\  on  the  ocreen  while  the  data  scrolls  beneath  them  (e.g.  the  headings 
on  a  chart). 

Data  display  -  Windows 
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Data  display  -  Windows 


5. 3.4.3  Operation,  in  addition  to  the  guidelines  below,  the  guidelines  of  Section  5.3.2  "Display 
Control"  should  also  apply. 

a)  Windows  should  be  consistent  in  terms  of  command  syntax  and  semantics.  Control  of 
window  operations  should  be  consistent  throughout  the  system. 

b)  As  appropriate  to  the  user  task,  windows  should  be  capable  of  the  following  operations: 
scrolling/panning,  resizing,  moving,  hiding,  activating,  deactivating,  copying  to/from,  zooming 
in/out,  tabbing,  and  undo-last. 

c)  For  text-only  windows  and  windows  used  for  scanning  data,  window  sizing  should  be 
constrained  such  that  the  small?':*  possible  wind'^w  will  contain  at  least  2  lines  of  text  /data.  Each 
window  should  have  variable  line  widths  (e.g,  80-160  characters)  selectable  by  the  user. 

d)  Keyboard  input  should  affect  only  the  active  window  designated  by  the  user. 

e)  Users  should  bo  able  to  specify  and  select  separate  data  windows  that  will  share  a  single 
display  frame.  The  system  should  provide  the  user  several  options  for  moving  between  active 
windows  (e.g.,  clicking  a  mouse  button,  tab,  cursor  keys,  or  function  key). 

f)  Within  a  session,  the  system  should  keep  track  of  the  windows  that  are  open  (but  not 
necessarily  active  or  displayed)  and  display  them  as  a  menu. 

g)  Automatically  updated  windows  should  have  display  freeze  capability.  When  a  window 
displays  automatically  updated  information,  the  user  should  have  control  over  the  rate  at  which 
automatically  updated  screens  are  scrolled  . 

h)  A  window  that  is  not  displayed  should  be  capable  of  sending  and  receiving  information. 

5.3.4.4  Feedback. 

a)  The  system  should  provide  immediate  and  unambiguous  feedback  concerning  which  active 

window  is  being  acted  upon. 

b)  When  the  user  is  communicating  with  a  closed  window  (e.g.,  sending  or  receiving 
information  between  windows),  the  system  should  provide  feedback  that  clearly  designates  the 
window(s)  involved. 

c)  If  windows  are  capable  of  different  modes  (e.g.,  real-time  data  display,  recap,  command 
input/selection,  etc  ),  the  system  should  provide  immediate  and  unambiguous  feedback  concerning 

which  mode  is  active. 

d)  When  a  display  is  frozen  (e.g.,  while  executing  a  Print  Screen  command),  the  system 
should  provide  immediate  and  unambiguous  feedback  and  the  user  should  be  prompted  to  return  to 
automatic  ..'fxiats  A  warning  flag  should  be  displayed  to  alert  the  user  to  significant  changes  in 
real-time  daha  tha'  occurred  while  the  display  was  frozen. 

Data  display  -  Windows 
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e)  If  a  user-requested  action  g  ,  closing  a  window)  would  result  in  lost  or  damaged  data, 
the  user  should  be  alerted  and  alternative  actions  recommended.  See  figure  47. 

Direct  manipulation  interface  Keyboard  Interface 

Save  before 
transmitting? 

(Y  or  N,  then  <RETURN>)  I 


FIGURE  47.  Acceptable  feedback  windows,  with  promoting  response  to  user  command. 

f)  The  system  should  be  capable  of  alerting  the  user  to  critical  information  that  becomes 
available  in  an  inactive  or  nondisplayed  window.  See  figure  49. 

5.3.5  Data  forms.  Forms  should  be  used  to  display  related  sets  of  data  in  separately  labeled  fields. 
5.3.5. 1  Format. 

a)  Visually  distinctive  fields  should  be  provided. 

b)  When  forms  are  used  for  data  entry  as  well  as  for  the  data  display,  the  format  for  data 

P  display  should  be  compatible  with  whatever  format  is  used  for  data  entry.  The  same  item  labels  and 

I  ordering  for  both  should  be  used. 

■  c)  The  ordering  and  layout  of  corresponding  fields  should  be  consistent  among  displays. 

I  5.3.5.2  Data  presentation. 

■  a)  Units  of  measurement  for  displayed  data  should  be  presented  in  the  label  or  as  part  of 

I  each  data  item. 


Aircraft  landing  weight  (Tons) 

1  3 

Aircraft  landing  weight: 

13  tons 

FIGURE  48.  Two  means  of  providing  data  element  units 
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Data  display  -  Data  Forms  -  Data  presentation 


P)  Long  data  items  of  mixed  alphanumeric  characters  should  be  divided  into  subgroups  of 
three  or  four  characters  separated  by  a  blank  or  by  other  symbol. 

c)  The  internal  format  of  frequently  used  data  fields  snouid  be  consistent  from  one  display  to 
another;  as  examples,  telephone  numbers  should  be  consistently  punctuated,  (703)  698-6225, 

time  records  consistently  punctuated  with  colons,  as  HH:MM;SS:  or  HH:MM  or  MM:SS.S,  and  date  as 
DD;MM;YY. 

d)  Blanks  (keyed  spaces)  should  be  distinguishable  from  nulls  (no  entry  at  all)  in  the 
display  of  data  forms. 

5. 3. 5. 3  Data  field  labels.  Eacn  data  field  should  be  identified  with  a  display  label  which  is  located 
close  to  the  data  fields  they  identify. 

5.3.6  Text. 

5.3.6. 1  Format. 

a)  Consistent  text  formats  should  be  provided  from  one  display  to  another,  and  should 
conform  to  MIL-STD-490. 

b)  When  tables  and  graphs  are  associated  with  text,  they  should  be  placed  as  closely  as 
possible  after  the  first  reference  within  the  text. 

c)  Information  should  be  placed  in  groups  to  permit  the  user  to  associate  or  compare  similar 
classes  of  information.  Grouping  may  be  accomplished  by  right  or  left  justification  of  columns  to 
establish  boundaries  of  group  areas,  spacing  between  groups,  lines  between  group  areas  or  under 
group  headings,  and  locating  items  to  be  compared  character-by-character  in  subsequent  lines  on 
the  display. 

d)  When  words  in  text  displays  are  abbreviated,  each  abbreviation  should  be  defined  in 
parentheses  following  its  first  appearance. 

e)  Critical  passages/information  snouid  be  highlighted  by  bolding/brightening,  color  coding 
or  other  means.  Capitalization  alone  should  not  be  used. 

f)  Where  possible,  series  of  related  text  should  be  displayed  in  a  list  rather  than  as 
continuous  text, 

5. 3. 6. 1.1  Lists. 


a)  Unless  dictated  by  the  amount  of  information  to  be  presented,  or  where  information  is  to 
be  composed,  lists  should  be  formatted  so  that  each  item  starts  on  a  new  line. 

b)  When  a  single  item  in  a  list  continues  for  more  than  one  line,  items  should  be  marked  so 
that  the  contmuation  of  an  item  is  obvious. 
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The  information  displayed  at  the  bottom  of  this  figure  is  distinct 
from  the  text  which  might  be  entered  here.  Other  means 
can  be  devised,  such  as  using  different  colors,  fonts,  display  window^ 
size,  and  delimiters.  In  this  example,  the  information  presented  are 
labels  for  selectible  file  and  editing  operations  that  may  be 
frequently  required  by  system  users.  On  the  bottom  of  this  figure  .  . 


In  this  example,  the  information  presented  in  inverse  video 
is  selected  for  deletion,  movement  to  another  area  of  text, 
duplication,  etc. 


L 

Save 

New  I 

XMIT 

Revert 

Print 

Quit  I 

y 

J 


FIGURE  50.  Example  of  text  hiahliahlinn 


c)  When  five  or  more  alphanumeric  characters  without  natural  organization  are  displayed, 
the  characters  should  be  grouped  in  blocks  of  three  to  five  characters  within  each  group  separated 
by  a  minimum  of  one  blank  space  or  other  separating  character  such  as  a  hyphen  or  a  slash. 

d)  Column  spacing  within  a  table  and  from  one  fable  to  another  should  be  uniform  and 
consistent. 

e)  Item  numbers  should  begin  with  one,  not  zero.  Numbering  should  start  with  one  when  it 
applies  to  counting  and  with  zero  when  it  applies  to  measurement. 

f)  Lists  should  be  arranged  in  a  recognizable  order,  such  as  cronological,  alphabetic, 
sequential  functional,  or  importance. 

g)  Where  a  list  is  displayed  in  multiple  columns,  the  items  should  be  ordered  vertically 
within  each  cc'jmn. 

h)  For  a  long  list  extending  more  than  one  displayed  page,  the  last  line  of  one  page  should  be 
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the  first  line  of  the  next  page. 


Data  display  -  Text  -  Format 


i)  For  hierarchical  lists,  such  as  outlines,  complete  identifiers  (e.g.,  "Paragraph 

4, 2. 2. 4. 8")  should  be  used  rather  than  omitting  the  repeated  elements  (e.g,,  "Subparagraph  8"), 

j)  Identifiers  should  not  be  indented,  but  titles  and  subtitles  should  be  indented  so  that  their 
structure  is  apparent. 

5. 3. 6. 1.2  Free  running  text. 

a)  Lengthy  textual  material  (over  several  display  screens)  should  be  displayable  in 
hardcopy  form  rather  than  requiring  the  user  to  read  it  on-line. 

b)  When  a  user  must  continuously  read  text  on-line,  at  least  four  lines  of  text  should  be 
displayed  at  one  time. 

c)  Text  should  be  presented  in  mixed  upper  and  lower  case. 

d)  Text  should  be  formatted  in  a  few  wide  lines  containing  at  least  50  characters  per  line, 
rather  than  in  narrow  columns  of  many  short  linos. 

e)  Displayed  paragraphs  of  text  should  be  separated  by  at  least  one  blank  line.  Paragraphs 
should  be  numbered. 

0  Consistent  spacing  between  the  words  of  displayed  text  should  be  provided  with  left 
justification  or  tines  and  ragged  right  margins.  Left  and  right  justification  may  be  used  if  it  can  be 
achieved  by  variable  spacing,  maintaining  constant  proportional  spacing  between  and  within  words, 
and  consistent  spacing  between  words  in  a  line. 

g)  Computer-generated  displays  of  textual  data,  messages,  or  instructions  snouia  lollow 
design  conventions  for  printed  text. 

5.3.6. 2  WQrding/stvle.''punctuation. 

a)  Text  displays  and  text  composed  for  user  guidance  should  be  concisely,  clearly  and  simply 
worded,  and  simple  sentence  structures  should  be  used. 

b)  Distinct  words  rather  than  contractions  or  comoined  forms  should  be  used  in  displayed 

text. 


c)  Where  possible,  affirmative  statements  rather  than  negative  statements  should  be  used, 
and  sentences  should  be  composed  in  the  active  rather  than  passive  voice. 

d)  When  a  sentence  describes  a  sequence  of  events,  it  should  be  phrased  in  that  order. 

e)  Use  of  hyphenation  should  be  minimized  and  conventional  punctuation  should  be  used. 
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5  3.3  Display  control. 

a)  When  the  user  is  scrolling  vertically  through  text,  the  present  and  end  locations  should 
be  displayed  on  the  viewable  portion  of  the  display:  e.g.,  "linos  24  through  46  of  428  lines". 

b)  Speed  ot  text  display  should  be  controllable  and  should  not  exceed  the  users  normal 
leading  speed. 

5.3.7  Tables 

5.3.7  1  Format. 

a)  In  tables  with  many  rows  or  columns,  a  blank  line,  dots,  or  other  distinctive  features 
should  be  inserted  after  every  third  to  fifth  row  or  column.  The  columns  in  a  table  siiould  be 
separated  by  blank  spaces,  or  by  some  other  distinctive  feature. 

b)  Tabular  data  should  be  organized  ir.  a  consistent,  recognizable  pattern.  Tabular  data 
should  be  displayed  in  a  left-to-right,  top-to-bottom  array. 

c)  When  tabular  data  extend  over  one  page  vertically,  the  columns  should  be  labeled 
identically  on  each  page.  Tabular  data  should  not  extend  horizontally  over  more  than  one  page. 

c)  Consistent  spacing  within  a  table,  and  from  one  table  to  another,  should  be  maintained. 


FIGURE  51.  Example  of  tabular  data  spacing 
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Data  display  -  Tables 


5,3.7. 1 . 1  Numeric  diilii- 

a)  Data  should  be  presented  to  the  operator  in  a  readily  usable  and  readable  format. 
Requirements  for  transposing,  computing,  interpolating,  or  mentally  translating  into  other  units 
or  numerical  basis  should  be  avoided. 

h)  Columns  of  numeric  data  should  be  justified  with  respect  to  a  fixed  decimal  point.  If 
!i  iore  IS  no  dccimai  point,  then  numbers  should  be  right-justified. 

c)  In  presenting  decimal  numbers,  trailing  zeroes  should  be  presented  to  the  level  of 
Significance  of  the  number. 

d)  For  hierarchical  lists  with  compound  numbers,  complete  numbers  should  be  displayed. 
5,3.7.'!  .2  Alphanumeric  data. 

a)  When  five  or  more  alphanumerics  are  displayed,  without  a  precedent  grouping 
organization  (as  in  telephone  numbers,  serial  numbers,  vendor  part  numbers,  etc),  characters 
should  be  grouped  in  blocks  of  three  to  four  characters.  If  a  series  is  to  be  10  units,  then  its 
structure  should  have  distinct  groups  of  3.  4,  3.  Groups  should  be  separated  by  a  minimum  of  one 
blank  chcnacter. 

b)  When  grouping  alphabetic  characters,  acronyms  or  abbreviations  should  be  used  in 
preference  to  randomly  selected  characters  that  have  little  relevance  to  the  system. 

c)  Complex  coding  systems  should  use  a  combination  of  alpha  and  numeric  designators  and 
grouping  should  be  applied.  For  example; 


POOR 

BETTER 

BEST 

954891282 

945  891  282 

A54  L91  Z28 

FIGURE  52.  Format  tor  complex  numbering  systems. 


d)  Columns  of  alphabetic  data  should  be  left  justified. 

5  3.7.1.3  Reference  tables. 

a)  When  tables  are  used  for  reference,  items  should  be  located  in  the  left  column,  and 
display  the  material  most  relevant  for  user  response  in  the  next  adjacent  column.  Associated  but 
less  significant  material  should  be  displayed  in  columns  further  to  the  right. 

b)  All  displayed  data  necessary  to  support  a  user  activity  or  sequence  of  activities  should  be 
grouped  together. 
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Data  display  -  Tables  -  Format 


c)  When  data  fields  contain  a  naturally  occurring  order;  e.g.,  a  chronology,  such  order 
should  be  reflected  in  the  organization  of  the  field. 

5.3. 7.1 .4  Data  comparisons.  A  tabular  format  for  data  display  should  be  used  when  information 
handling  requires  detailed  comparison  of  ordered  sets  of  data.  Where  dala  items  must  be  compared 
on  a  character-by-character  basis,  data  should  be  vertically  structured. 


POOR 

BETTER 

A  B 

453  E63  902  453  363  902 

A  243  WQ4  113 

E  243  WU4  113 

FIGURE  53.  Two  means  to  format  data  to  be  compared  fA  and  BT 


5.3. 7.2  Labeling/identifving  data. 

a)  Each  individual  field  should  be  labeled.  The  user  should  not  have  to  rely  on  contextual 
clues  alone  to  identify  a  field.  Table  row  and  column  labels  should  be  presented  in  terms  familiar 
to  the  user. 

b)  Labeling  units  of  measurement  should  be  part  of  column  labels,  or  placed  after  the  first 
row  or  column  data  entry. 


a)  Graphics  displays  should  be  used  when  displaying  data  showing  relations  in  space  or  time, 
when  users  must  quickly  scan  and  compare  related  sets  of  data,  or  when  users  must  monitor 
changing  data;  e.g.  bearing  angles,  environmental  conditions. 

b)  Consistent  logic.  Standard  formats,  and  labeling  should  be  provided  each  method  of 
graphic  presentation. 

c)  Graphically  displayed  information  should  be  limited  to  user  information  needs  and  task 
requirements.  Critical  data  should  be  highlighted. 

d)  When  needed  to  view  graphics,  pictures,  diagrams,  or  maps  in  detail,  zooming  capability 
should  be  provided.  When  a  display  has  been  expanded  from  its  normal  coverage,  a  graphic 
indicator  of  the  position  in  the  overall  display  of  the  visible  section  should  be  provided. 

e)  A  scale  should  be  provided  for  maps  and  related  displays. 

f)  When  on-line  graphic  displays  must  be  printed,  users  should  be  able  to  display  the 
material  exactly  as  it  will  appear  in  the  printed  output. 
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5.3.8. 1  Format. 

a)  Label  formats  should  be  consistent;  for  example,  labels  consistently  placed  over  the 
displayed  points  with  which  they  are  associated. 

b)  As  needed  to  support  user  tasks,  reference  indices,  baselines  and  text  annotations  should 
be  included  in  graphic  displays.  Textual  data  annotation  should  be  provided  where  precise 
information  is  required. 

c)  Normal  orientation  for  labels  should  be  used;  e.g.,  labels  should  be  displayed  horizontally 
for  the  vertical  axis  of  a  graph. 

5.3. 8.2  Coding  and  svmboloqv. 

a)  Symbol  meanings  should  be  standard  and  should  look  like  the  objects  or  processes  they 
represent. 

o)  When  used,  simple  texture  codes  should  be  used  rather  than  elaborate  patterns. 

c)  Where  possible,  the  movement  of  data  elements  under  computer  control  should  have  an 
animation  quality. 

d)  Where  sequential  relations  between  display  elements  requires  highlighting,  animation 
may  be  used;  for  example,  connectivity  might  be  emphasized  by  an  arrow  moving  repeatedly 
between  two  displayed  elements. 

5. 3. 8. 3  Curves  and  line  graphs. 

a)  Curves  and  line  graphs  should  be  used  for  displaying  relations  between  two  continuous 
variables,  as  in  showing  data  changes  over  time. 

b)  Unless  required,  use  of  three-dimensional  scales  should  be  avoided. 

c)  Curve  and  line  graphs  should  convey  enough  information  to  allow  the  reader  to  interpret 
the  data  without  referring  to  additional  sources. 

d)  When  curves  must  be  compared,  they  should  be  displayed  in  one  combined  graph. 

e)  Figure  and  title  elements  should  be  clearly  identified. 

5. 3. 8. 3.1  Axes. 

5. 3. 8. 3. 1.1  Design. 

a)  The  horizontal  (X-axis)  should  be  used  to  plot  time  or  the  postulated  cause  and  the 
vertical  (Y-axis)  should  be  used  to  plot  a  caused  effect. 
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b)  When  graphed  data  represents  only  positive  numbers,  the  graph  should  be  displayed  with 
the  origin  at  the  lower  left.  When  the  data  include  negative  values  and  the  axes  extend  in  both 
directions  from  a  zero  point,  the  origin  should  be  displayed  in  the  center  of  the  graph. 


c)  Unless  required  for  classification,  use  of  broken  axes  should  be  restricted. 

d)  When  scaled  data  will  contain  extreme  values,  the  X-axis  should  appear  at  both  the  top 
and  bottom,  and  the  Y-axis  should  appear  at  both  the  left  and  right  sides  of  the  graph,  and  grid  lines 
should  be  provided. 


5.3. 8.3. 1.2  Markinas  and  labels. 


a)  Values  on  an  axis  should  increase  as  they  move  away  from  the  origin. 

b)  Both  the  X-axis  and  Y-axis  should  be  clearly  labeled  with  title,  symbol  (as 
appropriate),  and  units. 


c)  Logical,  mathematical  subdivisions  should  be  indicated  along  each  axis.  Each  axis  interval 
should  be  marked:  but  to  avoid  clutter,  usually  only  every  other  interval  (major  division)  is 
marked. 


5. 3. 8. 3. 2  Scales. 

a)  Each  scale  axis  should  be  labeled  clearly  with  its  description  and  measurements  units. 


b)  Where  users  must  compare  graphic  data  across  a  series  of  charts,  the  same  scale  for  each 
chart  should  be  used.  When  users  must  compare  aggregate  quantities  within  a  display,  or  within  a 
series  of  displays,  scaling  of  numeric  data  should  begin  with  zero. 


c)  Graphs  should  have  a  single  scale  for  each  axis.  Where  possible,  common  scales  for 
complex  graphics  should  be  provided. 


d)  Linear  scales  should  be  used  in  preference  to  logarithmic  or  other  non  linear  scales. 


e)  Except  where  convention  or  customary  divisions  exist,  scales  should  be  constructed  with 
graduations  at  standard  intervals  of  1 ,2, 5,  or  10  (or  their  multiples  by  1 0)  for  labeled  divisions. 
Intervening  graduations  should  be  consistent  with  the  labeled  scale  interval. 

5.3. 8. 3.3  Legends.  Where  possible,  each  curve  within  a  single  graphic  should  be  identified 
directly  by  an  adjacent  label,  rather  than  by  a  separate  legend.  If  a  legend  is  displayed,  the  codes 
should  be  ordered  in  the  legend  to  match  the  spatial  order  of  their  corresponding  curves  in  the 
graph  itself. 
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5.3.8.3.4  Multiple  Curves. 

a)  In  charts  displaying  multiple  curves,  curves  representir.  data  of  particular  significance 
should  be  highlighted. 

b)  Line  coding  to  distinguish  curves  should  be  provided.  Consistent  line  codes  should  be  used 
to  represent  corresponding  data  in  a  series  of  charts. 

c)  Curves  representing  planned,  projected  or  extrapolated  data  should  be  distinguishable 
from  solid  curves  representing  actual  data.  Where  curves  must  be  compared  to  a  critical  value,  a 
reference  index  in  the  chart  should  be  provided.  Where  users  must  evaluate  the  difference  between 
two  sets  of  data,  a  difference  curve  should  be  displayed. 

d)  Where  curves  represent  cyclic  data,  extending  the  graph  to  repeat  uncompleted  portions 
of  the  displayed  cycle  may  be  provided. 

5.3.8.3.5  Surface  charts. 

a)  When  curves  represent  all  of  the  portions  of  a  whole,  surface  charts  may  be  used  to 
display  aggregated  amounts.  The  areas  defined  below  the  curves  should  be  textured  or  shaded. 

b)  Data  categories  in  a  surface  chart  should  be  ordered  such  that  the  least  variable  curves 
are  displayed  at  the  bottom  and  the  most  variable  at  the  top. 

c)  Where  space  permits,  areas  of  surface  charts  should  be  labeled  directly  within  the 
textured  or  shaded  bands. 

d)  Cumulative  curves  may  be  used  to  show  cumulative  totals.  Cumulative  curves  should  not 
be  used  to  extract  quantitative  or  rate  of  change  data. 


Coinparison  of  annual 
maintainance  costs  for  two 


Fiscal  Year 


FIGURE  55.  Example  of  a  surface  chart, 
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5. 3. 8. 3. 6  Grids. 

a)  When  necessary  grids,  should  be  piovided  to  aid  in  data  interpretation. 

b)  Grids  should  be  unobtrusive,  thinner  than  data  curves,  and  should  be  invisible  behind 
depicted  objects  and  areas  such  as  the  bars  on  a  bar  chart. 

5.3. 8.4  Bar  charts  and  histograms. 

a)  Bar  graphs  may  be  used  when  comparing  a  single  measure  (e.g.,  number  of  eligible 
recruits,  thousands  of  dollars,  etc.)  across  a  set  of  several  entities  (e.g.,  geographic  regions,  level 
of  education,  religion,  etc.)  or  for  a  variable  sampled  at  discrete  intenrals. 

b)  Histograms  (bar  graphs  without  spaces  between  the  bars)  may  be  used  when  there  are  a 
great  many  entities  or  intervals  to  be  plotted. 


Aircraft  A 


Aircraft  B 

Aircraft  C 


Aircraft  D 


Comparison  of  payloads 
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FIGURE  56.  Example  bar  chart. 
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5.3. 8.4.1  Format. 

a)  In  a  related  series  of  bar  graphs,  a  consistent  orientation  of  the  bars  (vertical  or 
horizontal)  should  be  adopted. 

b)  When  data  must  be  compared,  bars  should  be  adjacent  to  one  another.  Adjacent  bars 
should  be  spaced  such  that  a  direct  visual  comparison  can  be  made  without  eye  movement. 

c)  A  reference  index  should  be  provided  when  displayed  values  must  be  compared  with  some 
critical  value. 

Actual  vs  planned  annual 
maintenance  costs  a 
hypothetical  aircraft 

50 
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□ 

Actual 

■ 

Planned 

FIGURE. 57.  Example  of  a  bar  chart  which  facilitates  d?ta  comparison 


d)  Stacked  bars  (total  measures  broken  down  by  segments)  may  be  used.  Order  of  segment 
stacking  should  be  by  variability  of  each  segment,  with  the  least  variable  segment  being  the  lowest 
or  leftmost  segnient,  and  the  most  variable  segment  being  the  highest  or  rightmost  segment. 

e)  Use  of  iconic  representations  of  quantitative  information,  such  as  when  a  silhouette  of  a 
person  represents  1000  people,  should  be  avoided. 

5. 3. 8.4. 2  Codino/labeling. 

a)  Charts  and  axes  should  be  clearly  labeled. 

b)  Important,  critical  or  frequently  referenced  information  should  be  highlighted. 
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c)  When  bars  are  displayed  in  pairs,  they  should  be  labeled  as  a  unit,  with  a  legend  or 
individual  distinguishing  labels  for  eacn  bar. 


5.3. 8.5  Flowcharts,  riowcharis  may  be  used  for  schematic  representation  ot  sequences  or 
processes,  as  an  aid  to  problem  solving. 

5.3. 8.5.1  Format. 


a)  Flowcharts  should  be  ordered  so  that  displayed  steps  follow  a  logical  order;  (e.g.,  a 
process  by  sequence  of  activity  or  by  decreasing  importance  to  mission  success). 


b)  When  there  is  no  inherent  logic  in  a  flowchart,  steps  should  be  ordered  to  minimize 
flowchart  size. 


c)  Tho  displayed  path  of  flowcharts  should  be  from  left  to  right,  from  mp  to  I?c**o.T!,  or 
clockwise. 


d)  Decision  points  should  require  a  single,  simple  decision. 


FIGURE  58.  Decision  block  complexity. 


e)  Decision  options  should  be  logically  ordered. 

f)  Decision  block  outcome  paths  should  be  consistent. 
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5.3. 8. 5. 2  Coding/labeling. 

a)  Symbol/shape  coding  and  line  coding  should  be  used  to  assist  in  identifying  elements  and 
flow  lines.  For  different  types  of  flowchart  elements,  a  consistent  coding  scheme  should  be  followed. 

b)  Legends  should  be  displayed  on  each  figure  and  title  and  each  element  should  be  clearly 
labeled. 

c)  Critical  steps/processes  in  a  flowchart  should  be  highlighted. 

5.3.8. 6  Maps  and  situation  displays.  Maps  and  situation  displays  should  be  used  to  display 
geographic  data,  i.e.,  direction  and  distance  relations  among  physical  locations. 

a)  Orientation  of  maps  and  situation  displays  should  be  consistent  or  under  user  control  (for 
example,  oriented  to  true  north,  magnetic  north,  or  vehicle  direction). 

b)  When  maps  present  large  geographic  areas,  a  consistent  method  of  projecting  the  earth’s 
curvature  on  a  flat  display  surface  should  be  specified  and  adopted  (e.g.,  mercator  projections  or 
equal  area  projections). 

c)  Distance  judgments  from  map  displays  should  be  supported  through  grid  overlays, 
pointing  devices,  or  other  means. 

5. 3. 8. 6. 2  Codino/markinq/labeling. 

a)  When  it  can  be  done  without  cluttering,  significant  features  of  a  map  should  be  labeled 
directly  on  the  display. 

b)  When  different  areas  of  a  map  must  be  defined,  or  when  the  geographic  distribution  of  a 
variable  must  be  indicated,  color  or  other  means  of  coding  should  be  provided. 

c)  Where  users  must  make  relative  judgments  for  different  colored  areas  of  a  display,  tonal 
codes  rather  than  spectral  codes  should  be  used. 

d)  Texture,  pattern  or  tonal  variation  coding  should  be  selected  so  that  the  darkest  and 
lightest  shades  correspond  to  the  extreme  values  of  the  coded  variable. 

e)  Highlighting  should  be  used  to  represent  data  of  particular  significance. 

5.3.8.6.3  Data  presentation. 

a)  Where  possible,  demographic  or  other  data  on  map  displays  (population  density,  troop 
strength,  etc.)  should  be  presented  graphically  rather  than  by  using  text  descriptions. 
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b)  When  it  is  necessary  to  show  the  geographic  location  of  changing  data  (e.g.,  troop 
movements),  auxiliary  graphic  elements  (such  as  symbols)  should  be  combined  with  a  map 
background. 

c)  A  stable  reference  for  changing  data  should  be  provided. 

d)  When  map  or  situation  data  categories  are  variable,  the  user  should  be  able  to  select  the 
categories  needed  for  information  presentation.  For  example:  in  monitoring  aircraft  for  collision 
avoidance,  a  user  might  choose  to  display  aircraft  tracks  within  a  particular  sector  and  altitude 
zone. 


e)  Complex  data  analysis  (such  as  determination  of  sight  lines  using  a  map  display)  should 
be  supported  by  computer  processing. 

5.3. 8. 6.4  Display  control. 

a)  When  a  map  exceeds  the  capacity  of  a  single  display  frame,  in  terms  of  extent  and  detail  of 
coverage,  panning  rather  than  paging  over  the  area  should  be  provided. 

b)  When  a  user  pans  over  an  extended  display,  an  indication  of  the  position  in  the  overall 
display  should  be  provided. 

5.3. 8. 7  Pictures  and  diagrams. 

a)  Pictorial  displays  should  be  used  to  show  representations  of  real  or  imaginary  objects  or 
processes;  (e.g.,  photo  interpretations,  panel  layout  concepts,  map  overlays). 

b)  Diagrams  should  be  used  to  show  spatial  relations,  with  selective  focus  on  the  data 
specifically  required  by  a  user's  task  where  a  full  pictorial  rendering  might  be  unnecessarily 
complicated.  Figure  59  presents  an  example  of  a  picture  display. 

5.3.8.7.1  Codino/labelinq. 

a)  Abstract  symbols  and  iconic  representations  may  be  used  to  denote  objects  within 
pictures  and  diagrams. 

b)  Symbols  should  be  standardized  and  a  legend  defining  symbols  should  be  displayed  or 
available  at  user  option.  See  figure  60. 

c)  Picture  or  diagram  data  of  particular  significance  should  be  highlighted. 


1  05 


MIL-HDBK-761A 


Data  display  -  Graphics  -  Pictures  and  diagrams 


5. 3. 8. 7. 2  Image  control. 

a)  Where  a  user  must  examine  an  object  from  different  perspectives,  the  user  should  be 
able  to  rotate  the  displayed  image. 

b)  When  users  must  analyze  pictorial  images  in  de  'il,  computer  aids  should  be  provided; 

(e.g.,  exploded  views,  edge/contrast  enhancement,  overlays). 

c)  When  diagrammed  data  exceed  the  capacity  of  a  single  display  frame  and  must  be  shown  in 
separate  sections,  an  overview  of  the  diagram  should  be  provided. 

d)  A  logical  linking  of  a  diagrams  various  sections,  and  an  easy  means  of  movement  from  one 
section  to  another,  should  be  provided  (e.g.,  by  panning). 

5.3,8. 8  Pie  charts.  A  pie  chart  should  be  used  only  to  show  the  relative  distribution  of  data  among 
categories:  e.g.,  for  displaying  data  that  represent  proportional  parts  of  a  whole.  Pie  charts  should 
not  be  used  when  the  viewer  is  to  extract  quantitative  information. 

5. 3. 8. 8.1  Format. 

a)  Partitioning  should  be  limited  to  five  segments  or  less.  Segments  should  be  labeled  and 
numbers  provided  to  their  segment  labels  to  indicate  the  percentage  or  absolute  values  represented 
in  the  display. 

b)  When  a  segment  of  a  pie  chart  requires  emphasis,  it  should  be  highlighted  by  special 
hatching  or  shading  or  by  displacing  it  slightly  from  the  remainder  of  the  pie.  See  figure  61 . 


Hypotnetical  data 
showing  distribution 
of  US  Armed  Forces  in 
the  southern  hemisphere 


FIGURE  61.  Example  of  a  pie  chart  with  segment  displacement 
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5. 3. 8. 8. 2  Codinq/labeling. 

a)  The  chart  and  each  segment  should  be  clearly  labeled.  If  a  segment  is  too  small  to  contain 
the  label,  the  label  should  be  placed  outside  the  segment  with  a  line  from  it  to  the  segment. 

b)  When  required,  quantitative  information  should  be  provided  on  the  chart. 

5. 3. 8. 9  Scatterolots. 

a)  Scatterplots  should  be  used  to  display  correlations  among  or  between  variables. 

b)  Data  of  particular  significance  should  be  highlighted.  When  scatterplots  are  grouped  in  a 
single  display  to  show  relations  among  several  variables,  means  to  highlight  selected  relations 
should  be  provided. 
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5.4  Job  performance  aids. 

5.4.1  General.  In  addition  to  the  guidance  which  follows,  job  performance  aids  display  design 
should  also  follow  the  guidance  provided  in  Section  5.4,  "Data  Display". 

5. 4. 1.1  User  control. 

a)  Standard  procedures  should  be  designed  for  similar,  logically  related  transactions. 

b)  When  techniques  adopted  for  user  guidance  may  slow  experienced  users,  alternative 
modes  should  be  provided  which  allows  bypassing  standard  guidance  procedures. 

c)  Explicit  actions  should  be  required  to  access  or  suppress  job  performance  aids. 

d)  Users  should  be  able  to  switch  easily  between  information  handling  transactions  and 
presentation  of  guidance  material. 

5.4. 1.2  Format. 

a)  Display  formats  should  be  consistent  and  readily  distinguishable  from  displayed  data. 

b)  Critical  user  guidance  should  be  highlighted  using  the  same  methods  used  to  highlight 
critical  items  in  data  display. 

c)  When  hierarchic  menus  are  used,  they  should  be  organized  and  labeled  to  guide  users 
within  the  hierarchic  structure. 

d)  A  standard  symbol  should  be  used  for  prompting  entry. 

5. 4. 1.3  Wording  and  style. 

a)  Wording  should  be  familiar  to  the  user,  oriented  to  the  task,  provide  guidance  directly. 

b)  Active  rather  than  passive  voice  shcu'.d  be  used  in  guidance  messages. 


POOR 

BETTER 

The  user  should  press  ENTER  to  continue. 

Do  not  enter  data  before  clearing  the  screen. 

Will  you  make  a  selection? 

Press  ENTER  to  continue. 

Clear  screen  before  entering  data. 

Select  one. 

FIGURE  62.  Examples  of  wording  style. 
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c)  Messages  should  be  worded  concisely,  using  consistent  grammatical  structures,  phrasing 
and  punctuation.  See  figures  64  and  65. 

d)  When  transactions  occur  by  a  sequence  of  steps,  the  same  sequence  should  be  used  in  the 
wording  of  user  guidance:  for  example,  "SAVE  data  before  QUITTING". 

e)  Coding  abbreviations  and  wording  conventions  should  follow  the  display  design  guidance 
presented  in  section  5.3.6,  "Text". 

5.4. 1.4  Speech  output. 

a)  Computer-generated  speech  output  may  be  used  for  guidance  messages  in  environments 
with  low  ambient  noise,  when  a  users  attention  may  not  be  directed  toward  a  visual  display,  or 
when  providing  a  visual  display  is  impractical. 

b)  Computer-generated  speech  messages  should  be  limited  in  number,  distinctive  from 
routine  messages,  short  and  simple. 

5.4. 1.5  Performance  monitoring.  In  applications  where  skilled  user  performance  is  critical  to 
oystem  operation,  automatic  computer  recording  and  assessment  of  user  performance  should  be 
provided,  in  terms  of;  data  accessed,  user  errors,  help  requests,  user  transactions  and  programs 
used.  Users  should  be  informed  o.  any  records  kept  of  individual  performance. 

5.4.1 .6  On-line  training.  Where  possible,  on-line  training  capability  should  be  provided  with 
different  levels  of  training  for  on-line  job  support  and  should  adapt  automatically  to  user  abilities. 

5.4.2  Data  display. 

5.4.2.1  Help  displays. 

a)  Users  should  be  able  to  request  help  and  obtain  detailed  on-line  guidance  by  using 
standard  actions  that  are  always  available. 

b)  Synonyms  for  standard  terminology  should  be  recognized  by  help  routines. 


HELP  DISK 

HELP  STORE 

HELP  FILE 

HELP  BACKUP 

HELP  SAVE 

HELP  ARCHIVE 

FIGURE  63.  Examples  of  possible  synonyms  to  access  file  saving  help. 
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TRAINING  BALANCE  REPORT  HELP 

This  report  displays  the  balance  of  funds  available  u)  i  tli  i  n 
your  d i u i s ion/of f ice  by  month  for  the  fiscal  year  funded. 
Planned  courses  following  todays  date  and  new  or  approved 
courses,  funded  only  by  the  Directorate,  are  displayed  in 
order  by  the  course  start  date.  Planned,  estimated  and 
actuol  costs  are  displayed  for  each  course  and  totalled 
monthly.  The  most  up-to-date  cost  factual,  estimated 
actual,  then  planned)  for  each  course  is  subtracted  from 
your  division's  allocation,  thus  representing  your 
division's  best  estimate  of  funds  available. 

In  addition,  an  audit  report  listing  those  courses  not 
included  in  the  above  report  is  displayed.  The  report 
represents  those  planned  courses  whose  start  date  is  prior 
to  todays  date  and  have  no  estimated  or  actual  cost.  Those 
courses  which  have  been  cancelled  are  also  displayed. 

Following  the  selection  of  this  report  option,  the  above 
reports  will  be  displayed  to  the  users  terminal. 


PRESS  ENTER  TO  CONTINUE 
JOB 


TRAINING  BALANCE  REPORT  HELP 

This  report  displays  training  funds  balance  by 
division/office  by  month  by  year. 


Order  of  precedence  for  funding  balance  cost  estimates  are: 

1.  Actual  costs,  if  not  available  then, 

2.  Estimated  costs,  if  not  available  then, 

3 .  Planned  costs 


An  audit  report  follows  the  training  balance  report.  Audit  reports 
list  courses  not  yet  started  and/or  are  not  cost  estimated  or  actual. 

Cancelled  courses  are  reported  as  part  of  the  audit  report. 


PRESS  ENTER  TO  CONTINUE 
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c)  Multilevel  help  should  be  under  user  control.  Users  should  be  able  to  browse  through 
on-line  help  displays.  1 

d)  Help  messages  should  be  tailored  to  task  and  transaction.  Requests  for  help  in  ambiguous 
contexts  should  initiate  a  dialog  in  which  the  user  can  specify  what  data,  message  or  command 
requires  explanation. 

e)  After  requesting  help,  the  user  should  be  provided  with  easy  means  to  return  to  the  main 

dialog. 

5.4. 2. 2  Information  presented. 

a)  Specific  user  guidance  information  should  be  available  for  display  at  any  point  in  a 
transaction  sequence. 

b)  Only  guidance  information  relative  to  transactions  of  interest  should  be  displayed. 

c)  During  transaction  sequences,  guidance  should  be  provided  telling  the  user  how  to 
continue. 


5.4.2.2.1  Status  information. 

a)  Indication  of  system  status  should  be  continuously  presented  to  users.  Active  operational 
modes  should  be  clearly  indicated  to  the  user. 


b)  Users  should  be  able  to  obtain  status  information  concerning  current  alarm  settings,  in 
terms  of  dimensions  (variables)  covered  and  values  (categories)  established  as  critical. 

c)  When  interaction  is  required  with  other  users  or  systems,  information  concerning  the 
others  status  should  be  provided. 


d)  -evel  of  system  performance  should  be  indicated  (e.g.,  SYSTEM  LOAD  HEAVY,  DELAYS  UP 
TO  30  SECONDS  MAY  BE  EXPECTED). 


5.4.2.2.2  Control  information. 


a)  A  general  list  of  help  control  options  should  be  available  and  should  be  displayed  in  logical 

groups. 


b)  Where  command  entry  is  used,  an  on-line  command  index  should  be  available. 

c)  Control  options  that  are  specific  to  individual  help  messages  should  be  indicated  on  the 

display. 


d)  Advisory  messages  or  prompts  should  be  provided  to  guide  users  in  accessing  help 
messages. 
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e)  Reference  material  describing  system  capabilities  and  procedures  should  be  available  for 
on-line  display. 

f)  Users  should  not  be  required  to  memorize  lengthy  sequences  or  to  refer  to  secondary 
written  procedural  references  to  access  help  messages. 

d)  Where  the  user  can  choose  help  data  to  display,  an  on-line  index  should  be  provided. 

e)  When  a  user  help  request  depends  upon  context  established  by  previous  entries,  an 
indication  of  that  context  should  be  provided  to  the  user. 


f)  Users  should  be  able  to  request  a  displayed  record  of  past  transactions. 


FIGURE  66.  Establishment  of  context  in  accessing  help  displays. 


5.4.3  Feedback. 

5.4.3. 1  Routine  feedback.  Computer  response  to  user  entries  should  be  rapid,  with  consistent 
timing  as  appropriate  for  different  types  of  transactions. 

5.4.3. 1.1  Information  presented. 

a)  Routine  feedback  should  be  provided  as  transactions  are  processed  and  completed. 

b)  Feedback  should  be  provided  for  all  user  interrupts,  indicating  when  the  system  has 
returned  to  a  previous  or  normal  status. 

c)  Indication  of  transaction  status  should  be  provided  whenever  complete  processing  will  be 
delayed. 

d)  When  requests  for  printed  output  are  handled  by  a  remote  printer,  feedback  for  print 
requests  should  be  provided. 
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5.4.3. 1.2  Format. 

a)  Displays  should  be  uniquely  identified  at  the  top  of  each  display  frame. 

b)  Selected  or  active  options  should  be  displayed  automatically  or  at  user  request. 

c)  Items  selected  to  perform  operations  should  be  highlighted. 

5.4.3.2  Error  feedback. 

a)  Error  feedback  should  be  provided  if  an  error  or  other  unexpected  event  prevents 
processing  and  should  be  displayed  within  2  seconds  of  the  entry  in  which  the  error  is  detected. 

b)  An  error  message  should  not  be  generated  as  wrong  data  are  keyed,  but  only  after  an 
explicit  ENTER  action  has  been  taken. 

c)  To  supplement  on-line  guidance,  system  documentation  should  contain  a  listing  and 
explanation  of  all  error  messages. 

d)  Conditions  requiring  special  user  attention  should  use  distinctively  coded  alarms. 

5.4.3.2.1  Information  presented. 

a)  Error  information  should  reflect  the  user's  point  of  view  in  terms  of  what  is  wrong  and 
what  can  be  done. 

b)  When  multiple  errors  are  detected  in  merged  commands  (e.g.,  SAVE/QIUT/LOG 
OFF  <ENTER>),  the  user  should  be  notified  of  each  occurrence. 

c)  When  a  user  repeats  an  entry  error,  feedback  should  be  distinguishable  from  the  first 
occurrence  to  avoid  uncertainty  whether  the  computer  has  processed  the  revised  entry. 

d)  Erroneous  entries  and  error  messages  should  be  displayed  until  corrections  are  made,  and 
should  not  be  displayed  after  the  error  has  been  corrected  or  is  no  longer  applicable. 

e)  When  a  process  is  completed  or  aborted  by  the  system,  the  user  should  be  informed  about 
the  outcome  of  the  process  and  any  requirements  for  subsequent  actions. 

f)  The  user  should  not  have  to  search  through  reference  material  to  interpret  system 
messages.  However,  erro*-  messages  may  refer  the  user  to  specific  on-line  documentation. 

g)  When  possible,  users  should  be  able  to  request  more  detailed  error  messages. 

5.4.3.2.2  Wording  and  style. 

a)  Error  messages  should  be  informative,  nonthreatening,  brief,  as  specific  as  possible,  and 
employ  neutral  wording. 
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b)  Wording  for  error  messages  should  be  appropriate  to  a  users  task. 


POOR 


'Error  ID#  27;  file  I/O;  Device  2’ 


BETTER  'File  TANK.DATA  was  not  found  on  Disk  M60A1-S1MWAM' 


FIGURE  67.  Example  of  error  feedbac!:. 

5.4.3.2.3  Cursor  positioning.  The  cursor  should  be  positioned  at  the  point  where  an  error  was 
detected. 

5.4.3.2.4  User  response. 


a)  Users  should  be  required  to  reenter  only  the  portion  of  a  data/command  entry  which  is 
not  correct  and  should  not  have  to  rekey  an  entire  command  string  or  data. 

b)  Users  should  be  required  to  confirm  destructive  entries  before  it  will  be  executed  by  the 
the  computer. 


1  1  5 


MIL-HDBK-761A 


This  page  intentionally  left  blank. 


1  16 


MIL-HDBK-761A 


Expert  systems 


5.5  Expert  systems. 

5.5.1  General. 

a)  Expert  system  development  should  be  based  on:  user  requirements;  preferred  dialog 
types;  knowledge  engineer  requirements:  operational  requirements;  and  mental  models  employed  by 
the  human  expert  and  the  user. 

b)  A  detailed  description  of  the  functional  transactions  between  the  system  and  user  should 
be  developed  and  validated  prior  to  specifying  the  internal  structures  of  the  system. 

c)  The  guidelines  for  UCI  display  and  control  designs  included  in  sections  5.1 , 5.3,  and  5.4 
should  also  apply  to  expert  system  development. 

5.5.1. 1  Representino  causality. 

a)  To  the  extent  possible,  the  expert  system  should  be  capable  of  identifying  and 
representing  causality  between  facts  contained  in  its  knowledge  base. 

u)  At  the  request  of  the  user,  the  expe..  oyotern  should  oe  capable  of  representing  fon/vard 
causality,  in  the  form  of  predictions,  and  backward  causality,  in  the  form  of  speculative 
reconstruction  of  events. 

5.5.1. 2  Specify  domains. 

a)  In  selecting  knowledge  (facts)  to  be  contained  in  the  knowledge  base,  both  a  domain  model 
and  a  set  of  domain  principles  should  be  established. 

b)  The  domam  model  should  contain  descriptive  causal  relationships  and  classification 
hierarchies,  including:  failure  modes,  conditions  and  effects;  symptoms;  measures/estimates  of 
criticality/priority;  and,  alternative  responses  (inciuding  effects/constraints). 

c)  The  set  of  domain  principles  should  contain  prescriptive  methods  and  heuristics, 
including:  hypotheses  to  be  developed;  data  to  be  acquired;  tests  to  be  conducted;  and,  decisions  to  be 
made. 

5.5.2  Dialog. 

a)  The  system  should  support  a  flexible  dialog  that  permits  either  the  user  or  the  expert 
system  k  initiate  an  action  or  request  for  information,  without  cancelling  an  ongoing  transaction. 

b)  The  user-expert  system  dialog  should  be  flexible  in  terms  of  the  type  and  sequencing  of 
user  input  it  will  accept. 

c)  When  inexperienced  users  are  required  to  interact  with  the  expert  system,  menu,  form 
filling,  query  or  question/answer  dialog  modes  are  preferred  over  command  language  dialog  modes. 
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d)  The  system  should  be  designed  to  permit  rapid  retrieval  of  previous  exchanges  between 
the  user  and  the  expert  system  for  the  current  transaction.  The  preferred  method  for  such 
retrieval  is  scrolling. 

e)  User-expert  system  information  exchange  should  be  based  on:  the  range  of  data  types 
which  will  be  input  by  the  user  (text,  numeric,  graphic):  the  extent  and  frequency  of  each  data 
type  entry;  how  user-generated  data  be  acquired  (e.g. ,  volunteered  by  the  user  at  the  start  a 
consultation,  elicited  by  the  expert  system  on  an  as-needed  basis,  etc. );  the  range  of  data  types 
which  will  be  output  by  the  expert  system  (text,  numeric,  graphic);  the  extent  and  frequency  of 
each  data  type  output;  and  pacing  of  user  queries. 

f)  For  the  mode  of  expert  system  dialog  selected  (natural  language,  etc),  the  appropriate 
guidelines  of  section  5.2,  "Diaiog/lnteraction  Control",  should  also  apply  to  expert  systems  dialog 
design. 

5.5.3  Problem  statement/input. 

5.5.3. 1  Problem  definition  and  consultation  planning. 

a)  The  expert  system  should  provide  the  capability  for  the  user  to  plan  a  strategy  for 
addressing  a  problem.  This  plan  may  include  data  to  be  acquired,  hypotheses  to  be  tested,  criteria 
for  accepting/rejecting  hypotheses,  etc. 

b)  The  capability  provided  by  the  expert  system  should  include:  planning  aids  (such  as  time 
lines,  worksheets);  an  evaluation  function  which  assesses  the  adequacy  of  the  user’s  plan  and 
recommends  revisions  where  necessary:  the  ability  to  form,  state  and  test  hypotheses  in  a  manner 
consistent  with  the  user's  plan;  and,  the  capacity  to  store  and  recall  plans. 

5.5.3. 2  Consultation. 

a)  The  expert  system  should  be  capable  of  supporting  a  complete  range  of  problem  solving 
strategies,  including:  reliability  (i.e.,  failure  rate);  conditional  probability:  syndrome/symptom 
analysis:  signal  tracing;  half-split;  and,  bracketing.  The  expert  system  should  be  capable  of 
accepting  direction  from  the  user  in  terms  of  which  strategy  to  employ. 

b)  The  control  strategy  should  support  both  forward  (data-driven)  and  backward 
(goal-driven)  chaining  to  allow  the  user  or  expert  system  to  provide  data  or  propose  a  new  or 
revised  goal,  as  appropriate,  for  the  transaction  underway. 

c)  The  system  should  be  capable  of  supporting  speculative  analysis  (e.g. ,  what-if 
scenarios)  by  providing  a  "reconnoiter  mode"  that  allows  the  user  to  investigate  the  effects  of  an 
action  without  actually  implementing  the  action. 

d)  Entering  a  reconnoiter  mode  should  require  an  explicit  command  by  the  user  and  should 
result  in  a  clearly  distinguishable  change  in  system  output  (e.g.,  a  blinking  reconnoiter  mode 
symbol)  to  ensure  that  the  user  is  apprised  of  the  change  in  operating  mode. 
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e)  The  expert  system  should  be  capable  of  providing  interactive  explanations  using  the  facts 
and  rules  contained  in  its  knowledge  base. 


What  would  happen  if. . .  ? 

Are  there  significant  side  effects  to.  .  .  ? 
How  do  X  and  y  interact? 

What  causes  x? 

What  are  the  results  (effects)  of  x? 
Given  X,  how  should  I  respond? 


FIGURE  68.  Types  of  auestiona  expert  systems  should  be  capable  of  handling. 


f)  The  knowledge  required  to  perform  ail  functions  allocated  to  the  expert  system  should  be 
directly  accessible  by  the  expert  system. 

g)  Requirements  for  the  expert  system  to  query  the  user  to  obtain  information  for  routine 
functions  should  be  minimized. 

h)  The  capability  for  the  user  to  supercede  the  current  request  for  information  from  the 
expert  system  in  order  to  input  information  related  to  a  different  transaction  should  be  provided. 

i)  The  user  should  not  have  to  complete  all  elements  (e.g.,  fields)  of  an  expert  system 
requested  form  in  order  to  complete  a  phase  of  a  transaction. 

5.5.4  Display. 

5.5.4. 1  Dynamic  information. 

a)  With  the  exception  of  mission-critical  information,  display  of  dynamic  information 
should  "freeze”  during  extended  explanation  sessions  to  ensure  that  a  significant  change  in  status 
does  not  escape  notice  by  the  user. 

b)  At  the  completion  of  the  explanation  session,  the  system  should  update  and  highlight  any 
changes  in  displayed  values,  and  request  acknowledgment  by  the  user. 

c)  If  mission-critical  information  becomes  available  during  an  extended  explanation 
session,  the  system  should  alert  the  user,  via  prompts  or  other  alarm  mechanisms,  and 
immediately  display  the  information  to  the  user. 

5.5.4.2  Graphics  interface. 

a)  The  expert  system  should  have  the  capability  to  graphically  .cpr?<'ent  its  rules  network. 
This  capability  should  be  available  to  the  user  as  an  adjunct  to  the  explanation  subsystem. 
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b)  Graphics,  such  as  a  system  schematic,  should  be  used  to  depict  relationships  between 
system  configuration  and  measurable  parameters. 

c)  To  the  extent  possible,  graphics  should  portray  system/component/process  status 
through  the  use  of  color,  shading,  or  similar  coding  techniques. 

d)  Coding  techniques  should  be  consistently  applied  across  the  expert  system. 

e)  The  guideline  of  Sections  5.2.8  "Iconic  Interaction",  5.3.6  "Graphics  Entry",  and  5.3.8 
"Graphics  [display]"  should  apply  to  expert  systems  graphic  interfaces. 

5.5.4.3  Off-line  printing. 

a)  The  expert  system  should  have  access  to  an  off-line  printer  to  allow  the  user  to  request 
hardcopy  of  screen  displays  (text  or  graphics),  summaries  of  extended  consultations,  lists  of 
rules/facts  invoked  during  a  consultation,  and  summaries  of  hypotheses  tested  and  data  employed 
during  a  consultation. 

b)  The  printer  may  be  used  as  an  alternative  display  device  to  free  up  the  primary 
workstation. 

5.5.5  Certainty  factors. 

5.5.5.1  Weighting  certainty  factors. 

a)  If  weighting  is  appropriate,  certainty  factors  should  reflect  a  weighted  combination  of 
prr’jabilistic  cost  -  benefit  judgements. 

b)  If  numerical  representation  is  used,  certainty  factors  should  reflect  the  criticality  of  a 
conclusion  with  regard  to  achieving  mission  success). 

c)  The  rationale  underlying  the  weighting  should  be  explicilly  encoded. 

5.5.5.2  Representing  certainty  factors. 

a)  The  rule  set  for  an  expert  system  should  be  capable  of  representing  certainty  factors  to 
the  user.  Certainty  factors  may  be  contained  in  the  data,  in  one  or  more  rules,  or  both. 

b)  Certainty  factors  should  be  represented  as  a  decimal  number  from  -1  to  +1 ,  with  -1 
indicating  absolute  certainty  that  a  fact  is  not  true,  and  +1  indicating  absolute  certainty  that  a  fact 
is  true. 


c)  Certainty  factors  displayed  to  the  user  should  reflect  the  cumulative  certainty  for  all 
elements  of  the  conclusion  being  drawn. 


Expert  systems  -  Explanation  facilities 
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d)  in  addition  to  numerical  values  of  certainty,  the  system  should  be  capable  of  providing 
some  indication  of  rationale  underlying  the  uncertainty,  such  as  conditions  when  the  rule  was 
invalid. 

5.5.6  Explanation  facilities. 

a)  The  expert  system  should  be  capable  of  explaining  its  behavior,  problem  solutions,  and 
knowledge. 

b)  At  any  point  during  a  consultation,  the  expert  system  should  be  capable  of  displaying  the 
rule  currently  being  invoked. 

c)  The  expert  system  should  automatically  record  all  rules  invoked  during  a  consultation. 

d)  Following  a  consultation,  the  explanation  facility  should  be  capable  of  recalling  each 
invoked  rule  and  associating  it  with  a  specific  event  (i.e. ,  question  or  conclusion)  to  explain  the 
rationale  for  the  event. 

e)  The  explanation  facility  should  be  able  to  search  the  knowledge  base  to  locate  rules  or 
items  of  knowledge  in  response  to  specific  inquiries  from  the  user,  to  alert  the  user  when  a 
problem  is  beyond  its  current  capabilities,  and  instruct  the  user  as  to  what  additional  knowledge  or 
rules  would  be  required  to  complete  the  transaction. 

f)  The  expert  system  should  be  able  to  respond  to  user  requests  to  clarify  or  restate 
questions  and  assertions. 

g)  The  system  should  be  capable  of  displaying  both  rule-based  and  descriptive  explanations, 
as  requested  by  the  user. 

h)  At  any  point  during  a  transaction,  the  expert  system  should  be  able  to  explain  which 
problem  solving  strategy  is  being  employed,  why  a  particular  strategy  was  selected,  and  the 
current  status  of  the  application. 

5.5.6. 1  Lanauaae/stvie. 

a)  The  presentation  of  information  to  explain  or  justify  the  behavior  or  knowledge  of  the 
expert  system  should  be  consistent  in  content  and  format  with  the  cognitive  strategies  and  mental 
models  employed  by  the  user,  particularly  when  the  user  and  the  expert  system  are  independently 
working  the  same  problem. 

b)  At  a  minimum,  the  explanation  facility  should  employ  the  same  nomenclature, 
abbreviations  and  acronyms  for  system  elements  as  those  employed  by  the  user. 

c)  The  system  should  be  capable  of  emulating  a  degree  of  "self-awareness"  by  portraying, 
via  the  explanation  facility,  the  knowledge  it  contains  concerning  the  application,  relevance  and 
validity  of  rules  and  knowledge  (facts)  contained  in  its  knowledge  base. 


Expert  systems  -  Explanation  facilities 
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processes  by  which  rules  and  facts  are  applied. 

e)  The  guidelines  of  Section  5.3.6  "Text  (display)"  should  be  applied  to  explanation  facilities 

design. 

5. 5. 6. 2  Strategy  explantion.  At  any  point  during  a  transaction,  the  expert  system  should  be  able 
to  explain  which  problem  solving  strategy  is  being  employed,  why  a  particular  strategy  was 
selected,  and  the  current  status  of  the  application. 

5.5. 6.3  Relation  to  rules  and  knowledge  base. 

a)  Rules  should  be  represented  explicitly  in  the  knowledge  base  and  encoded  in  such  a 
manner  that  it  is  accessible  to  the  explanation  facility  and  can  be  translated  for  human 
understanding. 

b)  The  content  and  detail  of  a  rule's  explanation/justificalion  should  be  consistent  with  the 
classification  of  the  rule. 

c)  For  most  systems,  rules  may  be  assigned  to  one  of  the  following  classes; 

1 )  identification  rules  (rules  based  on  the  properties  of  a  class) 

2)  causal  rules  (rules  whose  premise,  action,  or  conclusion  are  related  by  a  causal 
argument 

3)  world  fact  rules  (rules  that  are  based  on  empirical,  common  sense  knowledge 
about  the  world) 

4)  domain  fact  rules  (rules  that  link  hypotheses  on  the  basis  of  domain  definitions). 

d)  Rule  exceptions  should  be  explicitly  contained  in  the  knowledge  base  and  should  be 
available;  to  the  user  as  part  of  the  explanation  facility. 

e)  The  explanation  facility  should  have  access  to  the  rationale  by  which  the  hypotheses  in  a 
rule's  premise  were  ordered. 

f)  The  rationale  for  ordering  hypotheses  should  be  explicitly  represented  for  the  following 
classes  of  hypotheses: 

1 )  hypotheses  related  to  personnel  health  and  safety 

2)  hypotheses  related  to  mission  success,  mission-critical  equipment  or 
mission-critical  data 

3)  hypotheses  related  to  nonmission-critical  equipment  or  data 

4)  hypotheses  related  to  mission  efficiency  and  economics. 

5. 5. 6.4  Levels  Qf  explanation. 

a)  The  level  of  detail  of  information  presented  as  part  of  an  explanation  or  justification 
should  be  under  the  control  of  the  user. 


Expert  systems  -  Explanation  facilities 


b)  The  user  should  be  able  to  specify  three  levels  of  detail:  rules  only,  brief  explanations 
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and  detailed  explanations. 

c)  Control  of  the  explanation  facility  should  be  designed  such  that  the  user  may  specify  the 
level  of  detail  as  a  default  option  at  the  beginning  of  a  transaction. 

d)  For  any  individual  explanation,  the  user  should  be  able  to  request  greater  or  lesser  detail. 

e)  Systems  employing  means-ends  analysis  as  an  element  of  the  control  strategy  should 
provide: 

1 )  a  description  of  the  current  state 

2)  a  description  of  the  goal  state 

3)  a  description  of  the  difference  between  the  current  state  and  the  goal  state 

4)  descriptions  of  all  candidate  operators  (rules),  including  the  type  and  amount  of 
difference  they  eliminate 

5)  a  description  of  the  strategies  for  transforming  the  current  state  or  revising  the 
goal  state. 

5. 5. 6. 5  Representing  reasoning.  When  representing  its  reasoning  process  to  the  user,  the  expert 
system  should  be  capable  of  describing  how  well  the  observed  data  support  each  hypothesis  under 
consideration  and  how  well  each  hypothesis  under  consideration  account  for  the  observed  data. 


1  23 


MIL-HDBK-761A 


This  page  intentionally  left  blank. 


1  24 


MIL-HDBK-761A 


Data  communication 


5.6  Data  communication. 

5.6.1  General. 

5.6. 1.1  User  control/procedures. 

a)  Data  transmission  functions  should  be  integrated  with  other  information  handlitig 
functions  within  a  system. 

b)  Procedures  for  preparing,  sending  and  receiving  messages  should  be  consistent  between 
transactions  and  other  information  handling  tasks. 

c)  Data  transmission  procedures  should  be  designed  to  minimize  memory  load  on  the  user 
and  to  minimize  required  user  actions. 

d)  Both  sending  and  receiving  messages  should  be  accomplished  by  explicit  user  action. 

e)  Users  should  be  provided  flexible  control  of  data  transmission,  in  terms  of  what,  when 
and  where  data  should  be  transmitted. 

0  Users  should  be  able  to  interrupt  message  preparation,  review,  or  disposition,  and 
resumption  should  be  from  the  point  of  interruption. 

5.6. 1.2  Wording  and  message  content. 

a)  Functional  task  oriented  wording  should  be  used  for  terms  in  data  transmission. 

b)  Transmitted  data  should  be  annotated  with  any  alarm/alert  conditions,  priority 
indicators,  or  other  significant  information. 

5.6.2  Message  preparation. 

5.6.2. 1  Procedures.  Procedures  for  composing  messages  should  follow  the  general  data  entry  and 
editing  procedures  presented  in  Section  5.3  "Data  Entry"  of  this  handbook.  Users  should  not  have 
to  learn  procedures  for  entering  message  data  that  are  different  from  general  data  entry. 

5. 6. 2. 2  User  control. 

a)  Users  should  be  provided  means  to  specify  data  to  be  transmitted  and  should  be  able  lo 
incorporate  existing  file  data  (including  other  messages  received  or  transmitted)  in  messages. 

b)  Users  should  be  able  to  prepare  and  transmit  messages  of  any  length. 

c)  Users  should  be  able  to  save  draft  messages  during  preparation,  or  upon  completion. 

d)  When  messages  must  be  transmitted  following  data  change,  the  user  should  confirm  th.ct 
the  data  are  ready  to  be  transmitted. 
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5. 6.2. 3  Format. 

a)  Unless  a  need  exists  for  a  specific  message  format  (encryption,  order  of  data  analysis, 
etc),  users  should  be  able  to  compose  and  transmit  messages  with  a  format  of  their  own  design,  and 
to  compose  and  transmit  messages  as  unformatted  text. 

b)  When  messages  must  conform  to  defined  formats  and  standards,  preformatted  forms 
should  be  available  to  users. 

c;  Where  possible,  the  system  should  provide  automatic  message/text  formatting  for 
optional  use. 


Distribution 

Sender  Information 

Priority: 

To:| 

JSmith 

ADDR; 

WalkNet  Box  #23014 

_ ^ _ 

Send  When?- 

Message; 

_ 7 

7^ 

Sender  information 

automatically  filled 

in  by  the  system 

Press  F1  for  HELP 

Press  F2  for  MENU  OPTIONS 

Press  F3  to  QUIT 

FIGURE  69.  Example  of  a  preformatted  message  preparation  form. 


d)  In  forms  preparation  for  transmission,  users  should  be  able  to  enter,  review,  and  edit 
data  on  any  display  organized  with  labeled  fields. 

e)  Users  should  be  able  to  enter,  review,  and  change  tabular  or  graphic  data  in  customary 
formats;  e.g.,  row/columns. 

5.6.3  Data  transmission. 

5.6.3. 1  Addressing  messages. 

5. 6.3. 1.1  User  control. 

a)  Users  should  be  able  to  specify  destinations  where  data  will  be  transmitted  by  system 
users  (as  individuals  or  groups),  other  work  stations,  terminals  (including  remote  printers),  or 
users  of  other  systems. 

b)  Users  should  be  able  to  edit  the  address  fields  in  the  header  of  a  message  being  prepared 
for  transmission. 


1  26 


MIL-HDBK-761A 


Data  communication  -  Data  transmission  -  Addressing  messages 


5.6.3. 1.2  Format. 

a)  A  basic  set  of  header  fields  (DATE,  TO,  FROM,  COPIES,  TIME,  etc.  that  can  be  interpreted 
by  all  systems  to  which  messages  will  be  sent)  should  be  provided. 

b)  Prompting  should  be  used  to  guide  the  user  in  specifying  the  address  for  a  message. 

c)  The  address  of  a  recipient  should  occur  only  once  in  a  message. 

5.6.3.1.3  Directories/distribution  lists. 

a)  Address  directories  should  be  provided  in  which  users  are  able  to  search  address 
directories  by  specifying  a  complete  or  partial  name,  or  other  address  information  and  are  able  to 
select  addresses  without  reentering  the  information. 

b)  Users  should  be  able  to  define  names  for  commonly  used  addresses,  to  save  those  in  a  file, 
and  to  address  messages  by  name. 

c)  Users  should  be  provided  with  information  about  distribution  lists  on  which  they  are 
included,  and  lists  they  are  authorized  to  use. 

c)  Users  should  be  able  to  create  and  modify  their  own  lists,  and  within  a  distribution  list, 
users  should  be  able  to  include  other  distribution  lists  as  well  as  individual  addresses. 

d)  Where  coordinated  review  of  messages  by  several  recipients  is  required,  the  sender 
should  be  able  to  specify  a  serial  distribution  so  that  a  message  will  be  passed  from  one  recipient  to 
the  next. 

5.6.3. 1.4  Validation  and  error  correction. 

a)  Computer  checks  for  address  accuracy  should  be  provided  (i.e.,  recognized  content  and 

format). 


b)  Users  should  be  required  to  correct  mistakes  before  initiating  message  transmission. 

c)  Users  should  be  able  to  print  copies  of  transmitted  messages. 

5.6.3.2  Initiating  transmission. 

a)  When  standard  messages  must  be  transmitted  (as  when  a  computer  is  monitoring  external 
events  and  reporting  data  change)  means  should  be  provided  to  initiate  transmission  automatically. 

b)  Automatic  queuing  of  outgoing  message  should  be  provided  to  reduce  user  involvement  in 
routine  transmission. 
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5.6.3.2.2  User  control- 

a)  Users  should  be  able  to  initiate  data  transmission  directly,  by  entering  an  explicit  SEND 
command. 

b)  Users  should  be  able  to  choose  whether  to  transmit  a  displayed  version  of  a  message,  or  to 
transmit  directly  from  stored  files. 

c)  Users  should  be  able  to  assign  priority  to  messages,  and  to  defer  liie  transmission  of 
messages  to  a  specific  date,  time,  or  by  later  action. 

d)  Message  transmission  should  be  provided  with  annotations  such  as  "RECEIPT  REPLY 
REQUESTED",  under  sender's  control. 

e)  Senders  should  be  able  to  cancel  or  abort  a  transmission  that  has  not  been  completed  or 
initiated. 

a)  Status  information  concerning  the  identity  of  other  system  users  currently  on-line 
should  be  available. 

b)  When  a  message  is  sent,  the  computer  should  append  the  sender's  address,  and  the  date  and 
time  of  message  creation  and  transmission. 

5.6.3.3  Controlling  transmission. 

a)  Transmitted  data  should  be  protected  automatically  with  parity  checks  to  detect  and 
correct  any  errors  that  may  occur. 

b)  Automatic  feedback  should  be  provided  for  data  transmission,  confirming  that  messages 
have  been  sent,  or  indicating  transmission  failures. 

c)  Only  one  copy  of  any  message  should  be  transmitted  to  an  individual  addressee. 

5. 6.3.3. 2  User  control. 

a)  Users  should  be  able  to  specify  what  feedback  will  be  provided  for  message  transmission, 
and  to  request  specific  feedback  for  particular  messages. 

b)  Users  should  be  able  to  recall  or  abort  transmissions  after  initiation,  if  messages  have 
not  been  received. 

c)  When  required,  automatic  record  (LOG)  keeping  should  be  provided. 
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5.6.3.4  Transmission  failure. 

a)  In  the  event  of  transmission  failure,  automatic  queuing  should  be  provided  to  preserve 
outgoing  messages. 

b)  If  message  transmission  fails,  automatic  storage  of  undelivered  messages  should  be 
provided,  and  the  sender  should  be  notified.  Notification  should,  if  possible,  include  an  explanation 
of  the  failure. 

5.6.4  Message  receipt. 

5.6.4.1  System  control. 

a)  Incoming  messages  should  be  automatically  queued  by  time  of  receipt,  message  priority, 
or  user  specification,  pending  subsequent  review  and  disposition  by  the  user. 

b)  Logs  of  messages  received  and  sent  should  be  automatically  maintained  by  the  system. 

5.6.4.2  User  control. 

a)  Users  should  be  able  to  specify  data  that  may  be  received,  by  specifying  receipt  priority 
or  other  means,  and  should  be  able  to  choose  what  device  (files,  display,  printer)  will  receive 
messages. 

b)  Users  should  be  able  to  specify  "filters"  based  on  message  source,  priority,  type,  or 
content,  that  will  control  notification  for  incoming  messages. 

c)  Users  should  be  able  to  assign  their  own  names  and  other  descriptors  to  received 
messages. 

d)  Users  should  be  able  to  discard  unwanted  messages  without  filing. 

5. 6.4.3  User  review  of  messages. 

a)  Means  should  be  provided  for  users  to  specify  message  summary  listing  orders. 

b)  Unless  required  for  security  or  other  procedure,  means  tor  review  of  messages  (in  their 
incoming  queue)  should  be  provided  without  requiring  user  disposition  (e.g.,  saving,  deleting, 
responding,  etc.). 

c)  Users  should  be  able  to  review  summary  information  about  the  type,  source,  and  priority 
of  queued  incoming  messages. 

d)  Display  designs  for  received  messages  should  be  consistent  with  general  data  display 
guidelines  presented  in  Section  5.3.6  "Data  Display  -  Text".  For  example,  in  terms  of  means 
provided  to  scroll  through  text,  saving  messages  as  a  file,  etc. 


1  29 


MIL-HDBK-761A 


Data  communication  -  Message  receipt 


chnijir'  ho  a^'9  ’n  onnr*3te  rcv'^v.-rri  mossages  AM!!C'idi''>jns  should  be  displayed  ano 
should  be  distinct  from  the  message  itself. 

f)  An  indication  of  message  size  should  be  included  in  message  summaries  and  at  the 
beginning  of  each  incoming  message. 

5.6.4.4  Format. 

a)  If  data  transmission  arrives  in  an  incompatible  format  (with  system  decoding  or  device 
capabilities) .  recipients  should  be  advised. 

b)  Incompatible  formats  should  not  destroy  the  incoming  message  or  any  ongoing 
transactions  of  the  receiver. 

5.6.4.5  Pata.display- 

a)  Users  should  be  notified  at  log-on  of  any  data  transmissions  received  since  last  use  of  the 

system. 


b)  Notification  of  arriving  messages  should  not  interfere  with  a  users  ongoing  tasks. 

c)  Priority  of  received  messages  should  be  indicated  in  applications  where  incoming 
messages  will  have  different  degrees  of  urgency,  i.e.,  different  implications  for  action. 

5.6.4. 6  Reply.  When  replying  to  a  message,  the  appropriate  address(es)  should  be  provided 
automatically. 
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0.7  Data 


5.7.1  General. 

a)  Clear  and  consistent  procedures  should  be  provided  for  different  types  of  transactions, 
particularly  those  involving  data  entry,  change,  deletion,  and  error  correction. 

b)  Where  possible,  the  system  should  deal  appropriately  with  user  errors  and  random 
inputs,  without  introducing  unwanted  data  change. 

5. 7. 1.1  System  control. 

a)  Automatic  measures  to  minimize  data  loss  from  computer  failure  should  be  provided. 

b)  Whenever  possible,  automated  measures  for  data  security  should  be  provided,  relying  on 
computer  capabilities  rather  than  on  humans. 

c)  When  a  proposed  user  action  will  interrupt  a  current  transaction  sequence,  automatic 
means  to  prevent  data  loss  should  be  provided. 

d)  Where  potential  data  loss  cannot  be  prevented,  the  user  should  be  warned,  and  the  action 
should  not  be  implemented  without  user  confirmation. 

LOGOFF 

The  file  'MESSAGE.TEXT  has  not  been  saved. 

SAVE  'MESSAGE.TEXT?  (Y  or  N):  Y 

SAVING  •MESSAGE.TEXT 
LOGOfFi 


FIGURE  70.  Example  of  a  too-off  warning  to  prevent  data  loss 


e)  When  function  keys  or  other  devices  are  not  needed  for  a  transaction  type  and  when  they 
.may  have  destructive  effects,  they  should  be  disabled  under  software  control  to  avoid  activation. 

f)  Automatic  defaults,  if  provided  for  control  entries,  should  protect  against  data  loss,  and 
should  not  contribute  to  the  risk  of  data  loss. 

5.7.1. 2  UseLactiflns- 

a)  Data  should  be  protected  from  inadvertent  loss  caused  by  the  actions  of  other  users. 

Users  should  be  able  to  designate  their  own  files  and  data  as  protected  from  the  actions  or  access  of 
others. 
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u)  t-requent  or  urgent  actions  should  be  easy  to  perform,  potentially  destructive  actions 
should  be  sufficiently  difficult  to  require  additional  user  attention. 

b)  Unless  real-time  computer  monitoring  is  performed,  data  should  be  changed  only  as  a 
result  of  explicit  user  actions. 

c)  Explicit  ?)nfion  to  select  destructive  modes  should  be  required. 

d)  Users  should  be  required  to  take  an  explicit  extra  action  to  CONFIRM  a  potentially 
destructive  or  critical  control  entry  before  it  is  accepted  by  the  computer  for  execution. 

e)  A  CONFIRM  action  should  be  distinctively  labeled. 

f,  Users  should  be  required  to  wait  for  computer  prompting  to  CONFIRM  so  that  the 
confirmation  will  constitute  a  second,  separate  action. 


TRANSMfT 

The  transmission  'READINESS  REPORT  has  not  been  encrypted 
ENCRYPT  'READINESS  REPORT?  (Y  or  N) ;  N 

••Please  CONFIRM  •• 

The  transmission  'READINESS  REPORT.'  should  be  encrypted. 
ENCRYPT  then  TRANSMIT?  (YorN):  Y 

ENCRYPTING . . . 

Message  'READINESS  REPORT  oK  at  1423  hours  on  25:4:87 
Enter  command:  | 


FIGURE  71.  Example  confirming  action  prior  to  command  execution. 


g)  Users  should  be  able  to  UNDO  an  immediately  preceding  control  action  that  may  have 
caused  an  unintended  data  loss. 

h)  Users  should  not  be  able  to  change  (delete,  edit,  etc.)  protected  or  controlled  data. 

5.7. 1.3  Simulation  and  training. 

a)  When  simulated  data  are  used  in  conjunction  with  system  functions  (e.g.,  during  training 
or  operability  tests),  actual,  unsimulated  data  should  be  protected. 

b)  Operational  system  use  should  be  clearly  indicated  and  distinguishable  from  simulated 
operations. 

Data  protection  -  General 
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5.7.1. 4  Dataxiisplay- 

a)  Computer  logic  that  will  generate  messages  or  alarm  signals  should  be  provided  to  warn 
users  (and  system  administrators)  of  potential  threats  to  data  security,  (i.e.,  of  attempted 
intrusion  by  unauthorized  persons). 

b)  A  continuous  indicatiori  of  the  current  operational  mode  (data  entry,  edit,  etc.)  should  be 
dibplayed,  particularly  when  transactions  migh'  '•esult  in  data  loss. 

c)  For  conditions  which  may  require  special  user  attention  lo  p-oicoi  against  data  loss,  an 
explicit  alarm  or  warning  message  should  be  provided  to  prompt  appropriate  user  ection. 

5.7.2  User  authentication. 

5.7.2. 1  Unauthorized  access.  A  limit  on  the  number  and  rate  of  unsuccessful  LOG-ON  attempts 
should  be  imposed  to  provide  a  margin  user  error,  while  protecting  the  system  from  persistent 
attempts  at  illegitimate  access. 

5.7.2.2  Identification  and  passwords. 

a)  LOG-ON  processes  should  be  designed  to  provide  prompts  for  all  user  entries,  including 
passwords  and  other  data  required  to  confirm  user  identity  and  to  authorize  data  access  privileges. 

b)  When  system  security  requires  more  stringent  user  identification  than  is  provided  by 
password  entry,  auxiliary  tests  may  be  used  that  authenticate  user  identity,  but  should  not  impose 
impractical  demands  on  users  memory. 

c)  Users  should  be  able  to  choose  or  change  their  own  passwords. 

d)  Where  data  protection  is  critical,  user  selected  passwords  should  be  tested  against  a  list 
of  common  passwords  ("me",  "66  Vette",  "ABC",  etc.)  or  commonly  known  user  data  (such  as  names 
spelled  backwards  "ydnA",  users  birth  dates,  etc.). 

e)  When  a  password  must  be  entered  by  a  user,  password  entry  should  be  private;  password 
entries  should  not  be  displayed,  but  display  echoes  (such  as  "*")  for  each  keystroke  should  be 
provided. 

f)  Unless  a  specified  period  of  inactivity  has  expired  or  under  special  security  procedures, 
whatever  data  access/change  privileges  are  authorized  after  identity,  authentication  should 
continue  throughout  a  work  session. 

5.7.3  Data  access. 

5. 7.3.1  Classified  data  protection. 

a)  When  displayed  data  are  classified  for  security  purposes,  a  prominent  indication  of 
security  classification  should  be  presented  in  each  display. 
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b)  When  classified  information  is  displayed,  some  rapid  means  for  suppressing  a  display 
should  be  provided. 

c)  Procedures  to  control  access  to  printed  or  printing  data  should  be  provided  rather  than 
prohibiting  the  printing  of  classified  information. 

d)  When  sensitive  data  may  be  exposed  to  unauthorized  access,  a  capability  for  encrypting 
data  should  be  provided.  Data  encryption  should  be  easily  reversible. 

5. 7.3.2  Record/log  keeping. 

a)  The  computer  should  automatically  keep  records/logs  of  data  access. 

b)  Users  should  not  be  relied  on  to  take  critical  record  keeping  actions. 

c)  Transaction  records  and  logs  should  be  stamped  with  user  identifiers,  time,  and  date. 
Provisions  should  be  made  to  control  requests  for  records  and  logs  of  data  transactions  with 
classified  mate.ia!. 


d)  Users  should  be  informed  concerning  the  nature  and  purpose  of  automated  recording  of 
individual  actions. 

e)  When  multiple  users  review,  enter,  or  modify  data  in  a  system,  they  should  be  able  to 
review  and  browse  data  changes  or  entries  made  by  other  users. 

5.7.3.3  Data  preservation. 

a)  When  protection  of  displayed  data  is  essential,  the  computer  should  maintain  control  over 
the  display  and  should  not  permit  a  user  to  change  "read-only"  data. 

b)  A  "read-only"  status  should  be  indicated  for  users  not  authorized  to  change  displayed  data. 

c)  Provisions  should  be  made  to  prevent  accidental  activation  of  potentially  destructive 
control  actions. 

d)  When  required,  display  formatting  features,  such  as  field  labels  and  delimiters,  should  be 
protected  from  change  by  users. 

e)  If  a  complete  file  is  to  be  deleted,  sufficient  information,  (name,  description,  si.:e.  date 
established,  date  last  changed,  etc.)  should  be  displayed  to  verify  the  file  for  deletion. 

f)  Users  should  be  required  to  confirm  destructive  entries. 

g)  The  prompt  for  a  CONFIRM  action  should  warn  users  explicitly  of  any  possible  data  loss. 
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h)  An  explicitly  labeled  CONFIRM  function  key,  different  from  the  ENTER  key  should  be 
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provided  for  user  confirmation  of  critical  control  and  data  entries. 


PCCR 

CONFIRM  DELETE 

BETTER 

CONFIRM  deletion  of  entire  'AIRFIELD'  file?? 

FIGURE  72.  Example  Prompts  for  a  CONFIRM  action 


i)  Data  loss  at  LOG  OFF  should  be  avoided  by  a  check  on  pending  transactions  and  display  of 
an  advisory  message  requesting  user  confirmation. 

j)  When  two  or  more  users  have  simultaneous  read  access  or  data  processing  results  from 
multiple  user-computer  interfaces,  the  operation  by  one  person  should  not  interfere  with  the 
operations  of  another  person,  unless  mission  survival  may  be  contingent  upon  the  preemption. 

k)  Provisions  should  be  made  so  that  the  preempted  user  can  resume  operations  at  the  point 
of  interference,  without  information  loss. 

5. 7.3.4  Data  entry/chanoe.  Procedures  for  data  entry  and  change  should  follow  guidelines 
presented  in  Sections  5.3  "Data  Entry",  5.2  "Dialogs/Interaction  Control,  and  5.4  "Data  Display". 

.5  7.4  Classified  data  transmission. 

5.7.4. 1  System  control. 

a)  Measures  provided  to  protect  data  during  transmission  (e.g.,  encryption,  parity  checks, 
buffering  until  acknowledgment  of  receipt)  should  be  applied  automatically,  without  the  need  for 
user  action. 

b)  A  copy  of  any  transmitted  message  should  automatically  be  saved  until  correct  receipt  has 
been  confirmed. 

c)  As  necessary,  automatic  queuing  of  incoming  messages  should  be  provided  to  ensure  they 
do  not  disrupt  current  classified  information  handling  tasks. 

5.7.4.2  User  actions. 

a)  When  a  user  must  confirm  the  identity  of  a  message  source,  computer  aids  such  as 
computer-generated  confirmation  codes  should  be  provided  for  that  purpose. 

b)  When  human  judgment  may  be  required  to  determine  whether  data  are  appropriate  for 
transmission,  users  or  a  system  administrator  should  be  provided  means  to  review  outgoing 
messages  and  confirm  release  before  transmission. 
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6.  NOTES 

(This  section  contains  information  of  a  general  or  explanatory  nature  that  may  be  helpful,  but  is 
not  mandatory). 

6.1  Intended  use.  This  handbook  is  intended  for  use  as  design  guidelines  for  analysis,  design,  and 
evaluation  of  computer  based  Management  Information  Systems.  It  is  not  intended  for  use  to 
express  binding  requirements  in  conceptual  and  other  eaiiy  acquisition  phases.  The  handbook  may 
be  applied  to  traditional,  as  well  as  non -developmental  items  (NDI)  acquisitions. 

6.2  Issue  of  DODISS.  When  this  handbook  is  used  in  acquisition,  the  applicable  issue  of  the  DODISS 
must  be  cited  in  the  solicitation  (see  2.1 .1  and  2.2). 

6.3  Subject  term  (kev  word)  listing. 

Data  Communication 
Data  Entry 
Data  Protection 
Design 

Diaiog/Interactive  Control 
Display 

Expert  Systems 
Human  Engineering  Guidelines 
Job  Performance  Aids 
Management  Information  Systems 
User-computer  Interface 

6.4  Changes  from  previous  issue.  Marginal  notations  are  not  used  in  this  revision  to  identify 
changes  with  respect  to  the  previous  issue  date  due  to  the  extensiveness  of  the  changes. 
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Checklists 


fO  N/A 


5.1 


a)  The  user  has  the  initiative  in  transaction  control,  and  system 
control  is  subordinate  to  user  control. 

b)  Users  provide  the  pace  of  transaction  sequences. 

c.)  Transaction  control  is  by  explicit  user  action. 

d)  Control  by  simultaneous  users  do  not  interfere  with  those  of 
other  users. 

e)  Transaction  options  areprovided  which  match  expected  user 
goals  and  tasks. 

5. 1.1.1  Log-on. 

a)  When  users  must  log-on  to  a  system,  log-on  is  a  separate 
procedure  that  is  completed  before  a  user  may  select  any  operational 
opfi''  ns. 

b)  The  log-on  frame  appears  as  soon  as  possible  on  the  display 
with  no  additional  user  involvement. 


c)  Log-on  delays  are  accompanied  by  an  advisory  message  to  tell 
the  user  status  and  when  the  system  will  become  available. 

d)  Knowledge  of  the  internal  mechanisms  and  other  technical 
aspects  of  the  system  is  rot  be  required  of  the  user  to  log-on  or 
otherwise  use  the  system. 

e)  Average  system  response  time,  if  affected  by  the  number  of 
on-line  users,  is  displayed  at  time  of  log-on.  This  message  is  not  in  code 
but  contains  specific  information  concerning  current  response  time  and 
the  periods  when  response  time  is  relatively  ouick. 

f)  After  completing  the  log-on  process,  the  user  is  able  to  start 
productive  work  immediately. 
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YES 


N/A 


NO 


5.1. 1.2  LQg:Qft- 

a)  If  there  are  pending  actions  and  the  user  requests  a  log-off,  the 
system  informs  the  user  that  these  actions  will  be  lost. 

b)  interactive  timesharing  systems  allow  time,  between  keyboard 
actions  before  automatic  log-off,  unless  a  longer  period  is  requested  by 
the  user. 

c)  An  audible  signal  is  presented  at  specified  intervals  prior  to 
automatic  log-off. 

d)  Where  possible,  open  files  are  saved  to  some  defined  file  name. 

5.1 .1.3  S.iJPElicity. 

a)  Transaction  control  is  simple,  flexible,  adaptive,  consistent, 
minimize  user  actions,  compatible  with  the  lowest  anticipated  user  skill 
level,  and  are  logical  in  terms  of  user  task  sequences  and  functions. 

b)  Users  are  able  to  predict  system  responses  to  their  actions. 

c)  Transaction  control  is  consistent  in  form  and  consequences  and 
employ  similar  means  to  accomplish  c'.milar  ends. 

d)  When  hierarchical  levels  are  used  to  control  a  process  or 
sequence,  the  number  of  levels  is  minimized. 

e)  Display  and  input  formats  are  similar  within  levels  and  the 
system  indicates  current  positions  within  a  sequence. 

5. 1.1. 4  Transaction  selection. 

5. 1.1. 4.1  Timing  and  pacing. 

a)  Users  are  able  to  select  transactions;  computer  processing 
constraints  do  not  dictate  transaction  control. 

b)  When  appropriate  to  task  requirements,  users  are  able  to 
specify  transaction  timing. 

5. 1.1. 4.2  Options  list/prompting. 

a)  A  general  list  of  basic  control  options  is  available  to  serve  as  a 
"home  base"  or  consistent  starting  point  for  control  entries. 


Checklist 


VES 


ND 


N/A 


b)  A  general  options  list  presents  options  grouped,  labeled  and 
ordered  in  terms  of  their  logical  function,  frequency,  and  criticality  of 
use. 


c)  A  list  of  the  control  options  that  are  specifically  appropriate 
for  any  transaction  is  displayed  by  listing  in  the  working  display  or  by 
user  command. 

d)  Information  that  the  user  needs  to  perform  transactions  is 
displayed  without  burdening  short  and  long  term  memory. 

e)  Transactions  never  leave  the  user  without  further  available 

action. 

f)  Transactions  provide  next  steps  or  alternatives. 

g)  Control  entry  prompting  is  provided. 

5.1 .1.4.3  Command  selection. 

a)  Task  oriented  wording  for  control  options  is  used  to  reflect  the 
t  users  view  of  the  current  transaction. 

I 

b)  Only  available  transaction  options  are  offered  to  users  and 
control  defaults  are  indicated. 

c)  A  consistent  control  option  to  continue  to  the  next  transaction 
is  provided. 

d)  User  interrupt  or  abort  functions  to  terminate  transactions  is 
provided. 

e)  The  requirement  to  learn  mnemonics,  codes,  special  or  long 
sequences,  and  special  instructions  is  minimized. 

5. 1.1. 4.4  Meroino  commands. 

a)  Users  are  able  to  key  a  sequence  of  commands  or  option  codes 
as  a  single  control  entry. 

b)  Users  are  able  to  assign  a  name  and  use  that  named  "macro" 
for  subsequent  command  entry. 

c)  For  control  entry  merging,  command  names,  abbreviations,  or 
option  codes  are  accepted  as  if  those  control  entries  had  been  made 
separately. 
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d)  Required  punctuation  of  merged  entries  is  minimized.  A 
standard  delimiter  in  separating  commands  is  used;  e.g.,  a  slash  {/). 

5.1. 1.5  Context  definition. 

a)  Transaction  context  is  provided  for  the  user. 

b)  Unless  contextual  interpretation  of  commands  would  have 
destructive  effects,  transaction  control  software  interpret  currents 
control  actions  in  the  context  of  previous  entries  without  requiring 
users  to  reenter  data. 

c)  Users  are  able  to  request  a  summary  of  the  results  of  prior 
transactions  to  determine  present  status. 

d)  When  context  for  transaction  control  is  established  in  terms  of 
a  defined  operational  mode,  the  operational  mode  is  displayed. 

e)  Users  are  able  to  review  control  parameters  that  are 
currently  operative. 

0  If  the  consequences  of  a  control  entry  will  differ  depending 
upon  context  established  by  a  prior  action,  a  continuous  indication  of 
current  context  is  displayed. 

g)  When  performing  an  operation  on  a  selected  item,  the  item  is 
highlighted. 

h)  Information  displayed  to  provide  context  for  transaction 
control  is  distinctive  in  location  and  format,  and  consistently  displayed 
from  one  transaction  to  the  next. 

i)  Displayed  options,  command  entry  areas,  prompts,  advisory 
messages,  and  other  displayed  items  relevant  to  transaction  control  is 
distinctive  in  position  and  format. 


j)  Formats  are  consistent  from  one  frame  to  the  next. 


5.1. 1.6 


a)  Where  possible,  use  of  abbreviations  and  acronyms  is  avoided. 

b) Where  not  possible,  standard  abbreviations,  acronyms,  and 
display  codes  conform  to  MIL-STD-12,  MIL-STD-411,  or 
MIL-STD-783. 
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YES 


ND 


N/A 


c)  New  acronyms,  if  required,  are  developed  according  to  the 
rules  of  MIL-STD-12.  Extent  of  deviation  from  abbreviation  rules  is 
minimized. 

d)  Abbreviations,  mnemonics,  and  acronyms  do  not  include 
punctuation. 

e)  When  abbreviations  are  used,  a  dictionary  of  abbreviations  is 
provided  to  the  user. 

f)  Abbreviations  are  unique,  distinct  and  unambiguous. 

g)  Using  abbreviations  does  not  confuse  the  user  or  add  to  system 
operation  time. 

5. 1.1. 7  Labeling  and  terminology. 

a)  Consistent  terminology  for  transaction  control  is  adopted. 

b)  Congruent  names  for  control  functions  is  adopted. 

c)  Transaction  wording  is  consistent  with  user  guidance  and 
frame  of  reference. 

d)  For  interpreting  user-composed  control  entries,  upper  and 
lower  case  letters  are  treated  as  equivalent. 

e)  The  length  of  individual  input  words  does  not  ixceeci  seven 
characters. 

5.1. 1.8  Promptino/structurina. 

a)  The  system  contains  prompting  and  structuring  features 
designed  to:  prompt  for  all  required  input  parameters;  request  additional 
or  corrected  information  from  the  user;  provide  orientation  to  the  user 
during  transactions;  and  indicate  when  errors  have  been  detected. 

b)  Prompts  inform  the  user  what  information  is  to  be  input. 

c)  Where  six  or  fewer  control  options  exist,  they  are  listed. 

d)  Where  more  input  options  exist,  an  example  of  the  type  of 
entry  that  is  required  is  presented. 


e)  The  system  prompts  for  all  required  input  parameters.  The 
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YES 

hD 

N/A 

level  of  prompting  detail  is  controllable  by  the  user. 

f)  Prompting  messages  appear  at  a  standard  location  on  the 

screen. 

5.1. 1.9  System  messaaes. 

a)  Message  language  is  distinct,  meaningful,  and  easily 
discriminated. 

b)  Humorous  or  sarcastic  messages  are  avoided. 

c)  Messages  make  the  user  feel  in  control. 

d)  Messages  do  not  present  the  system  as  a  person. 

e)  When  a  message  appears  on  the  screen,  both  the  content  of  the 
message  and  the  action  required  by  the  user  is  explicit. 

f)  Messages  detailing  the  users  status  is  displayed. 

5.1.1.10  Feedback. 

a)  Positive  feedback  is  provided  for  all  control  entries. 

b)  Completion  of  transaction  processing  is  indicated  by  feed  back 
messages. 

c)  When  system  functioning  requires  the  user  to  standby, 
periodic  feedback  is  provided  to  indicate  normal  system  operation. 

d)  Successive  periodic  feedback  messages  differ  in  wording  from 
presentation  to  presentation,  or  are  otherwise  indicated. 

5.1.1.11  Alarms. 

a)  Where  alarm  conditions  are  not  predefined  by  functional, 
procedural,  or  legal  requirements,  users  are  able  to  define  the 
conditions  that  will  result  in  computer  generation  of  alarm  messages. 

b)  Alarms  are  distinctive  and  consistent. 

c)  Users  are  provided  with  a  simple  means  of  acknowledging  and 
turning  off  noncritical  alarm  signals  without  erasing  any  displayed 
message  that  accompanies  the  signal. 

1 

j 
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d)  It  users  are  required  to  acknowledge  a  special  or  critical 
alarm  in  some  special  way,  acknowledgment  does  not  inhibit  or  slow  user 
response  to  the  alarmed  condition. 

5.1.1.12  System  response  time. 

a)  Computer  response  time  to  user  entries  is  appropriate  to  time 
constraints  imposed  by  the  task  or  mission,  specific  data  processing 
applications,  and  type  of  transaction. 


b)  The  guidelines  of  Table  1  are  used  as  guidance  for  maximally 
acceptable  system  response  time. 
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ND 

N/A 

Key  Response 

From  key  depression  until  positive 
response;  e.g.,  "click"  or  display  echo 

Key  Print  (echo) 

From  key  depression  until  appearance  of 
character 

Page  Turn 

From  end  of  request  until  first  few  lines 
are  visible 

Page  Scan 

From  end  of  request  until  text  begins  to 
scroll 

Data  Field 

Entry 

From  selection  of  field  until  visual 
verification 

Function 

Selection 

From  selection  of  command  until 
response 

Pointing 

From  input  of  point  to  display  of  point  or 
pointing  device 

Drawing/ 

Sketching 

From  input  of  point  to  display  of  point, 
line,  arc,  etc. 

Local  Update 

Change  to  image/display  using  local  data 
base,  e.g.,  new  menu  list  display 

Host  Up-date 

Change  where  data  is  at  host  in  a  readily 
accessible  form,  e.g.,  a  display  scale  change 

File  Update 

Image/display  update  requiring  access  to  a 
host  file 

Simple  Inquiry 

From  command  until  display  of  a  common 
message 

Complex  Inquiry 

Response  message  which  requires  seldom 
used  calculations  in  graphic  form 

Error  Feedback 

From  entry  of  input  until  error  message 
appears 

Table  1. 

Acceptible  System  Response  Times. 
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5.1.1.13 


a)  Dialog  type  matches  task  requirements  and  user  abilities. 

b)  Question  and  answer  dialog  may  be  used  for  routine  data  entry 
tasks,  where  data  is  known  and  ordering  can  be  constrained,  for  users 
with  little  or  no  training,  and  where  computer  response  is  expected  to  be 
moderately  fast. 

<'1  Form  filling  dialog  may  be  used  where  flexibility  in  data  entry 
is  needed,  where  users  are  moderately  trained,  where  computer 
response  may  be  slow,  and  as  an  aid  for  composing  complex  control 
entries. 

d)  Menu  selection  dialog  may  be  used  for  tasks  that  involve  choice 
among  a  constrained  set  of  alternatives,  where  little  entry  of  arbitrary 
data  is  required,  where  users  have  little  training,  when  a  command  set  is 
too  large  to  commit  to  user  memory,  and  where  computer  response  is 
relatively  fast. 

e)  Function  keys  may  be  used  in  conjunction  with  other  dialog 
types  for  tasks  requiring  a  limited  number  of  control  entries,  as  an 
immediate  means  to  accoiiipiisii  frequent  or  control  transactions,  or  for 
criteria  control  entries. 


0  Command  language  dialog  may  be  used  for  tasks  involving  a 
wide  range  of  control  entries,  where  users  are  highly  trained  or  will  use 
the  system  frequently,  and  for  tasks  where  control  entries  may  be  mixed 
with  data  entries  in  arbitrary  sequence. 

g)  Query  language  dialog  may  be  used  for  tasks  emphasizing 
unpredictable  information  retrieval  with  moderately  trained  users. 

h)  Constrained  natural  language  dialog  may  be  used  in 
applications  where  task  requirements  are  broad  ranging  or  poorly 
defined,  and  where  little  user  training  can  be  provided. 
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YES 

K) 

N/A 

5.1.2  Question  and  answer  dialog. 

a)  Questions  are  displayed  separately,  posing  of  compound 
questions  is  avoided. 

b)  When  computer  posed  questions  are  interrelated,  answers  to 
previous  questions  are  displayed;  users  are  not  required  to  remember 
prior  answers  to  provide  context  for  current  questions. 

c)  As  appropriate,  question  sequence  is  compatible  with  source 
documents. 

5.1 .3  Form  fiilina  dialog.  In  addition  to  the  guidelines  contained  here, 
the  guidelines  of  section  5.2,  "Data  Entry",  and  Section  5.2.4,  "Form 

Entry",  are  applied  to  the  design  of  form  filling  dialogs. 

a)  As  appropriate,  defaults  for  control  entry  in  form  filling  are 
provided. 

D)  uontroi  lorms  and  formats  are  presented  in  a  consistent  and 
logical  format. 

5.1.4  Menu  selection  dialog. 

a)  Each  related  group  of  menu  options  permit  only  one  selection 
by  the  user. 

b)  Where  multiple  options  can  be  selected,  they  are  identified,  by 
label  or  by  option  coding. 

c)  All  available  options  are  explicitly  and  completely  displayed 
for  a  selected  menu. 

d)  Users  are  able  to  distinguish  between  available  and  unavailable 
options, 

e)  Unavailable  menu  options  are  displayed  along  with  available 

options. 

f)  An  input  prompt  clearly  indicates  to  the  user  that  the 
computer  is  waiting  for  a  response  and  a  standard  symbol  is  used  for 
prompting  entry. 

g)  Feedback  for  menu  selection  is  provided. 

5. 1.4.1  Format. 
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a)  Logically  related  options  within  a  list  are  grouped. 

b)  Groups  are  segregated  by  lines  or  other  means. 

c)  Unless  constrained  by  available  display  space,  related  menu 
options  are  formatted  as  a  single  column  list. 

d)  Menu  options  are  logically  ordered  and  grouped,  by  frequency 
of  use,  importance,  functional  relations,  or  sequence  of  use. 

e)  Where  ordering  cannot  be  determined  by  frequency  of  use, 
importance,  functional  relations,  or  sequence,  alphabetic  ordering  is 
used. 

f)  Menus  provided  in  different  displays  or  contexts  are  designed 
so  that  option  lists  are  consistent  in  wording  and  ordering. 

g)  Pop-up,  pull-down,  and  windowed  menus  are  displayed  in 
consistent  screen  locations  for  all  modes,  transactions,  and  sequences. 


h)  Menus  are  distinct  from  other  displayed  information. 


5. 1.4. 2  Labeling  and  terminology. 

a)  An  explanatory  title  for  each  menu  is  provided. 

b)  Where  menu  options  are  grouped  in  logical  subunits,  each 
group  is  provided  a  descriptive  label  that  is  distinctive  in  format  from 
the  option  labels  themselves. 

c)  Menu  options  are  worded  as  commands  rather  than  as  questions 
to  the  user. 

d)  When  menu  selection  is  used  in  conjunction  with  command 
language,  menu  option  wording  is  consistent  with  command  language. 

5. 1.4. 3  Menu  option  selection. 


a)  Menu  selection  from  displayed  options  is  implemented  by 
direct  pointing,  or  indirect  pointing  devices. 

b)  Where  direct  pointing  devices  are  used  in  menu  selection,  a 
sufficient  pointing  area  is  provided  to  preclude  selection  errors. 
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VES 


ND 


N/A 


c)  Where  indirect  pointing  devices  are  used  in  menu  selection,  a 
large  pointing  area  for  option  selection  is  provided,  including  the  area  of 
the  displayed  option  label,  plus  a  half-character  distance  around  the 
label. 


d)  When  menu  selection  pointing  is  via  cursor  control  keys  or 
tabbing,  the  cursor  is  automatically  placed  at  the  first  listed  option. 

e)  Experienced  users  are  able  to  bypass  a  series  of  menu 
selections  and  make  an  equivalent  command  entry  directly,  without  using 
pointing  or  cursor  control  devices. 

0  When  equivalent  keyboard  commands  are  provided  as  means  of 
menu  selection,  they  are  displayed  as  part  of  the  menu  option  label. 

5. 1.4. 3. 2  Key  coded  menu  selection. 


a)  Menu  selection  by  keyed  entry  may  be  used  when  menu 
selection  is  a  secondary  or  occasional  means  of  control  entry,  or  where 
short  option  lists  are  needed. 


b)  Options  are  coded  by  the  first  letter  or  several  letters  of  their 
displayed  labels,  rather  than  by  arbitrary  numeric  codes. 

c)  When  menu  items  are  coded,  a  standard  display  area  for  code 
entry  is  provided,  and  the  cursor  is  placed  in  the  command  entry  area. 


d)  Codes  associated  with  each  option  is  displayed  in  a  consistent, 
distinctive  manner. 


e)  One  (1)  letter  codes  for  menu  selection,  rather  than  assigning 
arbitrary  letter  or  number  codes,  are  provided. 

f)  Coding  of  menu  options  is  consistent  among  display  screens  and 
system  use  contexts. 


5. 1.4. 4  Hierarchic  menu  design. 

a)  When  menu  selection  must  be  made  from  a  long  list, 
hierarchic  menus  for  sequential  selection  is  provided,  bul  the  number  of 
hierarchic  levels  is  minimized. 

b)  Each  menu  option  list  has  4  to  8  options,  menus  with  less  than 

3  options  are  avoided. 
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c)  A  general  menu  of  basic  options,  as  the  top  level  menu,  is 
provided  which  is  as  unambiguous  as  possible. 

d)  Menu  elements  subordinate  to  top  level  menus  are  logically 

related. 

e)  Hierarchic  menus  are  structured  to  permit  immediate  user 
access  to  critical  or  frequently  selected  options. 

f)  Hierarchic  menus  minimize  the  number  of  steps  required. 

g)  Users  have  to  make  only  one  control  action  to  move  to  the  next 
higher  le'^el,  end  a  separate  simple  control  action  is  required  to  return 

to  the  general  menu  at  the  top  level. 

h)  Design  and  use  of  hierarchic  menus  is  consistent  across  task 
and  transaction  contexts. 

i)  The  current  position  within  menu  structures  is  indicated  when 
hierarchic  menus  are  used. 

j)  Hierarchic  menu  control  options  are  distinct  from  menu 
branching  options. 


a)  Once  a  command  has  been  composed,  an  explicit  enter  or 
execute  is  provided. 

b)  Standard  techniques  for  editing  commands  is  provided. 

c)  If  a  command  entry  is  not  recognized,  user  is  able  to 
revise/replace  the  command. 

d)  If  a  command  entry  may  cause  delays,  delete  or  modify  data,  or 
have  other  potentially  adverse  consequences,  the  user  is  required  to 
review  and  confirm  a  displayed  interpretation  of  the  command  before  it 

is  executed. 

5. 1.5,1  Labeling  and  terminology. 

a)  Commana  language  is  designated  so  that  a  user  can  enter 
commands  in  terms  of  functions  desired. 


b)  Command  names  and  language  are  meaningful,  use  familiar 
wording,  and  be  distinctly  and  consistently  worded. 
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c)  Coc<os  are  designed  to  aid  memory. 

d)  If  a  system  will  have  many  novice  or  infrequent  users,  the 
system  recognizes  a  variety  of  synonyms  or  alternative  syntax  for  each 
word  defined  in  the  command  language. 

e)  Where  possible,  commands  are  selected  such  that  common 
misspelling  errors  do  not  represent  valid  commands  . 

f)  Words  and  abbreviations  in  a  command  language  are 
distinctive. 

g)  Commands  do  not  consist  only  of  non-alphanumeric  characters. 

5. 1.5.2  Format,  syntax  and  layout. 

a)  A  standard  display  area  for  command  entry  is  provided.  When 
possible,  command  entry  is  located  at  the  bottom  of  the  screen. 

b)  Command  language  functions  are  organized  in  groups  for  ease 
of  learning  and  use. 

c)  Foi  infrequent  or  untrained  users,  syntactic  complexity  is 
minimized. 

d)  Command  language  syntax  is  consistent  across  different 
transachons. 

5. 1.5. 3  Keying  requirements. 

a)  Required  use  punctuation  is  minimized:  where  required,  a 
standard  delimiter  (sucn  as  a  /)  is  used. 

b)  Blanks  in  comrmand  entry  is  ignored  by  the  system. 

c)  Users  are  able  to  use  abbreviated  forms  of  any  command  of 
more  than  h  rtiaiacters. 

5. 1.5. 4  Job 

a''  U  o;i:,  ,srij  able  to  request  guidance  information  necessary  to 
determine  required  parameters  or  options  in  a  command  entry,  or  to 
determine  avaJablo  options  for  a  command. 

b,  WiiiHo  p^ossible,  guidance  information  is  accompanied  with 
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graphic  examples  of  command  content  and  syntax. 

c)  A  general  list  of  basic  commands,  with  appropriate  command 
format,  is  provided. 

5.1.6  Query  and  natural  language  dialogs. 

5. 1.6.1  Terminology. 

a)  The  wording  of  a  query  specifies  what  data  are  requested,  not 
how  to  find  the  data. 

b)  A  query  language  is  designed  so  that  it  reflects  a  natural  data 
structure  or  organization. 

c)  Users  are  able  to  employ  alternative  forms  when  composing 

queries 

d)  Where  possible,  need  for  quantifiers  ("less",  "without", 
"excluding")  in  specifying  queries  is  minimized. 

5.1.6  2  Limiting  and  combining  queries. 

a)  When  a  query  may  result  in  a  large-scale  data  retrieval,  the 
user  is  required  to  confirm  the  transaction  or  take  further  action  to 
narrow  the  query  before  processing. 

b)  Query  language  includes  logic  elements  that  permit  users  to 
link  sequential  queries  as  a  single  entry,  such  as  "and",  "or",  etc. 

c)  A  query  language  is  capable  of  linking  sequential  queries  by 
use  of  statements  such  as,  "of  those  records  retrieved..."  or  "how  many  of 
the  remaining  candidates..." 

5.1.7  Function  keys. 

5. 1.7.1  Labeling  and  identifying. 

a)  Function  keys  are  distinctively  labeled. 

b)  If  key  function  is  variable,  current  active  function  is 
appropriately  labeled  by  adjacent  screen  location  or  other  means. 

c)  Function  keys  status  is  indicated. 


d)  Unneeded  or  disabled  function  keys  are  disabled  and  so 
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indicated  by  the  system. 

5. 1.7.2  Single  and  double  keying. 

a)  Keys  controlling  frequently  used,  critical,  or  time  constrained 
functions  permit  single  key  action  and  do  not  require  double  keying. 

b)  Double-keyed  functions  are  logically  paired  and  consistently 

logical. 

c)  Keys  perform  labeled  functions  with  a  single  activation,  and  do 
not  change  its  function  with  repeated  activation. 

5.1. 7.3  Feedback. 

a)  Feedback  is  provided  for  function  key  activation. 

b)  When  system  functioning  requires  the  user  to  standby, 
periodic  feedback  is  provided  to  indicate  normal  system  operation. 

5. 1.7.4  Format  and  layout. 

a)  Function  keys  are  grouped  in  distinctive  locations  on  the 
keyboard. 

b)  Frequently  used,  important,  or  critical  function  keys  are 
placed  in  the  most  convenient  locations. 

c)  The  layout  of  function  keys  is  compatible  with  their 
importance. 

d)  Physical  protection  is  provided  for  keys  with  potentially 
disruptive  consequences. 

5. 1.7. 5  Modes/function. 

a)  When  a  function  is  continuously  available,  the  function  is 
assigned  to  a  single  key. 

b)  Key  functions  in  different  operational  modes  are  consistent  or 

similar. 


c)  When  the  functions  assigned  to  a  set  of  keys  change  as  a  result 
of  usei  selection,  the  user  is  provided  an  easy  means  to  return  to  the 

base-level  functions. 
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d)  Where  possible,  experienced  users  are  able  to  define  their  own 
key  functions. 

5.1.8  Iconic  interaction. 

a)  Icons  may  be  used  to  graphically  represent  operations, 
processes  and  data  structures. 

b)  Icons  may  be  used  as  means  of  exercising  control  over  system 
functions,  components,  and  data  structures. 

c)  Iconic  representations  are  not  used  when  display  resolution  is 


d)  If  icons  are  used  to  represent  control  actions  in  menus,  a  label 
is  associated  with  each  icon. 

e)  Icons  are  consistent  and  predictable  across  operating  modes 
and  across  applications. 

f)  Icons  are  graphically  designed  to  the  processes  or  operations 
they  represent,  by  use  of  literal,  functional,  or  operational 
representations. 

g)  Abstract  or  humorous  representations  are  avoided. 

5.1.9  User  transaction  interrupts. 


a)  Means  to  interrupt  or  cancel  transactions  are  provided,  are 
distinctive,  and  occur  only  by  explicit  user  action. 

b)  User  interrupts  and  aborts  do  not  modify  or  remove  stored  or 
entered  data. 


c)  As  appropriate  to  specific  transactions,  the  following 
interrupts  are  provided: 

1 .  CANCEL  (or  UNDO)  erases  any  immediate  changes  and 
restore  the  display  to  its  previous  version. 

2.  BACKUP  returns  the  display  to  the  last  previous 
transaction. 

3.  REVIEW  returns  to  the  first  display  in  a  defined  transaction 
sequence,  permitting  the  user  to  review  a  sequence  of  entries  and  make 
necessary  changes.  REVIEW  is  nondestructive. 

4.  RESTART  or  REVERT  cancels  any  entries  made  in  a  defined 
transaction  sequence  and  return  to  the  state  at  the  beginning  of  the 
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sequence.  When  data  entries  or  changes  will  be  nullified  RESTART 
action,  users  are  required  to  CONFIRM  tne  RESTART. 

5.  END  (or  EXIT)  concludes  a  repetitive  transaction  sequence. 

6.  PAUSE  and  CONTINUE  temporarily  interrupts  a  transaction 
sequence  without  change  to  data  or  control  logic.  When  PAUSE  is 
selected,  a  PAUSE  status  indication  is  presented. 

7.  SUSPEND  preserves  (saves)  current  transaction  status 
when  a  user  leaves  the  system,  and  resume  at  that  point  when  the  user 
again  logs  on  the  system.  When  SUSPEND  is  selected,  an  indication  of  the 
SUSPEND  status  is  presented. 

5.1.10  Error  manaaement. 

a)  Users  are  able  to  edit  a  command  during  its  composition  before 
making  an  explicit  ENTER  action. 

b)  Users  are  able  to  stop  a  control  process  at  any  point  in  a 
sequence  to  correct  an  error. 

c)  Interface  software  deals  appropriately  with  all  possible 
control  entries,  correct  and  incorrect. 

d)  System  and  software  is  able  to  distinguish  between  program 
errors,  equipment  failures,  and  operator  errors. 

e)  System  and  software,  where  failures  result  in  shutdown,  allow 
for  minimum  loss  of  work  performed. 

5.1.10.1  Error  detection. 

a)  If  only  a  portion  of  a  merged  command,  or  an  entered  string  of 
commands,  can  be  executed,  the  user  is  alerted  and  guidance  provided  to 
permit  correction,  completion,  or  cancellation  of  the  merged  command. 

b)  Wt;en  an  error  is  detected  in  a  string  of  command  entries,  the 
system  eitfier  consistently  executes  to  the  point  of  error,  or  consistently 
require  users  to  correct  errors  before  execution. 

c)  If  a  menu  selection,  function  key,  command,  etc.  entered  is 
invalid  or  incqr.r.ttivo  at  the  time  of  selection,  no  action  results  except  a 
display  of  an  a'fvisory  message  indicating  what  functions,  options,  or 

comm, df, os  <jri;  , appropriate. 

•a  ' '  mossages  indicate  why  control  input  was  rejected  and 
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what  corrective  actions  may  be  taken. 

b)  Where  possible,  error  messages  distinguish  between  syntax 
errors  and  keying  errors. 

c)  Error  messages  and  guidance  that  will  not  fit  on  the  display 
contains  references  to  on-line  documentation  which  will  provide  further 
guidance,  users  do  not  have  to  refer  to  secondary  written  procedural 
references. 

d)  Error  messages  are  displayed  with  the  rejected  input  and  the 
portion  of  the  input  in  error  is  highlighted. 


5.1.10.'’  '='• 


a)  When  a  command  entry  is  in  error,  is  not  recognized  or  is  not 
appropriate,  users  is  able  to  correct,  without  reentering,  the  command. 

b)  Entry  of  corrections  requires  an  explicit  action,  and  requires 
the  same  ENTER  action  for  reentry  that  was  used  for  the  original  entry. 

c)  Easy  means  to  return  to  the  main  dialog  after  error  correction 
is  provided. 
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5.2  Data  entry  . 

5.2.1  General. 

5.2. 1.1  System  response  time  and  user  pacing. 

a)  The  system  acknowledges  user  inputs  rapidly,  preferably 
within  0.2  seconds  after  data  entry. 

b)  Users  are  able  to  pace  data  entry,  without  limitations 
controlled  by  computer  processing  or  exteriiai  events. 

5.2.1 .2  Editing  during  entry. 

a)  Users  are  able  to  perform  simple  editing  during  data  entry, 
without  entering  special  editing  modes. 

b)  Users  are  able  to  change  entries  by  consistent  means. 

c)  Users  are  able  to  enter  data  via  a  consistent  mode,  without 
having  to  change  modes. 

d)  When  inserting  words  or  phrases,  items  to  be  inserted  are 
displayed  as  the  final  copy  will  appear. 

e)  During  input  data  editing,  the  system  automatically  displays, 
or  offers  to  display  via  prompt,  information  to  be  modified. 

5.2. 1.3  Data  entry  feedback. 

a)  Data  entered  appear  on  the  users  primary  display  on  a 
stroke-by-stroke  basis. 

b)  The  system  confirms  completion  of  a  data  entry  action  by 
display  of  confirmation  message  or  other  means  to  indicate  successful 
data  entry. 

c)  Erru.'  messages  are  displayed  to  indicate  unsuccessful  data 

entry. 


d)  Feedback  is  provided  for  repetitive  data  entries  by  system 
regeneration  of  data  entries. 

e)  The  user  is  alerted  when  the  system  cannot  interpret  or 
recognize  an  abbreviated  data  entry.  Where  possible,  the  system 
questions  the  user  to  resolve  uncertainty. 


YES  ^D  N/A 


5. 2. 1.4  Data  entry  defaults. 

a)  Where  inputs  have  consistent  data,  the  user  is  able  to  define 
default  values,  codes  or  strings.  The  system  carries  the  data  to 
subsequent  forms,  text  strings,  etc. 

b)  When  default  modes  are  provided,  the  user  must  be  able  to 
define,  modify,  remove,  inhibit  or  enable  defaults  at  any  time. 

c)  Users  are  capable  of  replacing  any  data  entry  default  value 
with  a  different  entry  without  changing  the  default  definition  for 
subsequent  fields. 

d)  On  initiation  of  a  data  entry,  defined  default  values  are 
automatically  displayed  and  highlighted. 

e)  The  user  is  able  to  press  one  key  to  confirm  the  default  values. 

5. 2. 1.5  Highlighting. 

a)  Highlighting  is  easily  recognizable  and  be  used  to  attract  the 
users  attention  to  active  fields,  special  conditions,  or  as  a  means  to 
provide  feedback. 

b)  Highlighting  does  not  interfere  with  the  readability  of 
displayed  information. 

c)  A  highlighting  technique  similar  to  that  used  on  the  VDT  is 
provided  for  printed  output. 

d)  Critical  data  is  highlighted  and  is  removed  when  it  no  longer 
has  meaning,  importance,  or  criticality. 

e)  Flashing  is  not  used  as  a  means  to  highlight  routine 
information. 


f)  Flashing  is  only  used  as  an  alerting/alarming  code. 


5.2. 1.6 


a)  A  clear  visual  identification  of  each  field  is  provided. 


b)  Field  delineation  cues  distinguish  basic  features  of  required 


entries. 
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c)  Active  data  entry  fields  are  indicated  by  highlighting  or  other 

means. 

d)  Active  data  entry  fields  provide  data  entry  prompts. 

5.2.1. 7  Explicit  user  a 


a)  In  general,  explicit  user  actions  are  required  to  initiate 

system  processing,  such  as  saving,  deleting  data  or  files,  and  do  not  occur 
as  a  result  of  other  system  commands. 

b)  An  explicit  ENTER  action  is  required  to  initiate  processing  of 
entered  data;  an  explicit  CANCEL  action  is  required  to  cancel  a  data  entry; 
and  an  explicit  DELETE  action  is  required  prior  to  deleting  any  text  or 
other  data. 

5. 2. 1.8  Keying. 

a)  Where  possible,  users  is  able  to  use  single  keystrokes  to  enter 

data. 

b)  Required  multiple  keying  is  avoided. 


c)  For  data  entry,  upper  and  lower  case  keys  are  treated  as 
equivalent. 

d)  When  entering  decimal  data,  the  system  recognizes,  but  does 
not  require,  terminal  decimal  points,  and  recognizes,  but  does  not 
require,  typing  of  leading  or  trailing  zeroes. 

e)  The  system  treats  multiple  and  single  spaces  as  equivalent. 
Users  are  not  required  to  count  spaces. 

f)  Keying  redundant  data,  data  already  known  by  the  system,  or 
data  that  can  be  computed  or  derived  is  not  required  except  for  special 
conditions  such  as  data  security.  A  glossary  links  information  from  a 
record  at  time  of  entry  so  that  keying  any  of  the  unique  elements  will 

retrieve  a  vrhoic  record. 


Q;  ( ;ode  I  input  data  (alpha  or  numeric)  is  kept  short,  preferably 

not  exct  ‘  .h'iq  5  /  cfiaracters. 

A.g  data  strings  is  partitioned,  as  in  telephone 
numbers,  into  .shorter  groups  of  three  to  five  characters,  separated  by 
blanks.  '  -o*  *  n  or  slashes,  for  both  entry  and  display. 
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5. 2. 1.9 


a)  When  analog  data  input  is  based  on  graphic  presentation  of 
information,  analog  means  of  data  entry  is  provided. 

b)  Where  analog  data  is  based  on  previously  quantified  data,  key 
entry  is  used  in  lieu  of  analog  entry. 

5.2.1.10  Hierarchical  data  input.  If  a  user  must  er  ’er  hierarchical 
data,  the  system  guides  the  specification  of  relations  in  hierarchical 
structures. 


5.2.1.11  Recurrent/derived  data  input. 

a)  When  possible,  routine  data  that  can  be  derived  from  computer 
records  are  entered  automatically. 

b)  When  possible,  computation  of  derived  data  is  provided. 

c)  Recurrent  field  entries  are  retrievable  for  user  acceptance. 

d)  Where  data  that  are  logically  related  to  other  entries  are 
accessible  to  the  computer,  the  computer  retrieves  and  enter  those 
redundant  data  items  automatically. 

e)  Cross-file  updating  is  provided  by  the  system.  Users  do  not 
have  to  perform  cross-file  updates. 

5.2.1.12  Speech  input. 

a)  Speech  input  is  used  only  when  more  reliable  methods,  such  as 
keying  or  pointing,  cannot  be  used. 

b)  Speech  input  is  not  used  as  a  means  of  transaction  control 
when  a  large  constrained  vocabulary  may  exceed  memory  capabilities  of 
the  user,  or  for  highly  complex  or  nebulous  operations. 

c)  A  limited  speech  input  vocabulary  is  used. 

d;  Spoken  entries  are  phonetically  distinct. 

e)  Input  feedback  and  simple  error  correction  procedures  are 
provided  for  speech  input. 

f)  Alternative  entries  for  speech  input  is  provided,  as  in  the  use 
of  EXiT,  FINISHED,  and  QUIT  to  terminate  a  session. 
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g)  Provide  PAUSE  and  CONTINUE  or  RESUME  option  for  speech 


input. 


h)  Where  word  boundaries  are  required  for  system 
interpretation,  boundaries  of  1 00  milliseconds  or  more  is  allowed  by 
the  system. 

i)  A  word  reject  capability  is  provided. 

5.2.2  Cursor  positioning. 

a)  Cursors  are  distinctive  and  easy  to  locate  at  any  position  on  the 

display. 


b)  Cursors  are  easliy  t  r3Cl'\GCi  35  they  move  through  the  display. 

c)  Cursors  do  not  obscure,  distract  or  impair  searching  for 
information  unrelated  to  the  cursor. 


d)  Cursor  positions  remain  stable  until  commanded  by  the  user 
or  the  system  to  move,  an  explicit  action  is  required  to  enable  or  activate 
a  designated  cursor  position. 


e)  Curj  Y  controls  provide  fast  and  accurate  cursor  placement; 
entry  of  a  designated  cursor  position  is  acknowledged  within  0.2  seconds. 


f)  Control  actions  for  cursor  positioning  corresponds  to  direction 
of  cursor  movement. 

g)  Where  cursor  positioning  is  required  as  part  of  a  keyed  data 
entry  task,  the  cursor  control  device  is  located  near  to,  or  integral  with, 
the  keyboard. 


5.2.2. 1  Data  entry  and  cursor  placement. 

a)  An  ENTER  action  for  data  items  results  in  entry  of  all  items 
regardless  of  where  the  cursor  is  placed  on  the  display.  The  user  is  not 
required  to  move  the  cursor  to  a  specific  field  of  a  display  to  perform  an 

enter  action. 


h)  User  required  actions  for  cursor  movement  are  minimal  for 
form  fil';ng  entry. 


c)  The  T  AB  key  is  used  to  move  the  cursor  to  the  next  data  field. 
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d)  The  TAB  key  does  not  signify  ENTER  or  acceptance  of  field 
contents. 


e)  Formats  are  organized  to  minimize  positioning  movements  of 
the  cursor.  If  there  is  a  predefined  HOME  position  for  the  cursor,  it  is 
consistently  positioned  on  displays  of  the  same  type. 

f)  Users  are  not  able  to  move  cursors  to  data  fields  which  cannot 
accept  data  or  where  existing  data  cannot  be  modified. 


5. 2. 2. 2  Gross  positioning/pointinq. 

a)  If  proportional  spacing  or  variable  sized  characters  are  used, 
the  system  automatically  places  the  cursor  in  the  correct  position  for 
entering  or  changing  data. 

b)  When  cursor  positioning  is  accomplished  in  discrete  steps, 
consistent  movement  magnitudes  are  provided  for  horizontal  steps  and 
vertical  steps.  However,  horizontal  steps  do  not  need  to  be  of  the  same 
magnitude  as  vertical  steps. 

c)  When  cursors  are  used  in  selecting  display  areas  a  large  area 
for  pointing  is  provided,  including  the  area  of  the  displayed  text  label, 
plus  a  half-character  distance  around  the  label. 

d)  When  cursor  positioning  is  the  sole  or  primary  means  of  data 
entry,  a  direct  pointing  device  is  used  in  preference  to  incremental 
stepping  or  slewing  (Xintrols. 

5. 2. 2. 3  Precise  positioninq/pointing. 

a)  Where  precise  pointing  is  required,  as  in  graphics  generation, 
a  point  designation  feature  is  provided. 

b)  A  continuously  operable  control  is  used  to  control  direct 
pointing,  rather  than  discrete  controls. 

5.2. 2.4 

a)  Use  of  multiple  cursors  is  avoided  unless  indicated  by  user 
task  requirements. 

b)  Where  multiple  cursors  are  used,  they  are  visually 
distinctive. 


c)  An  indication  of  cursors  which  are  active  is  provided. 
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d)  Where  separate  control  is  provided  for  multiple  cursors, 
pointing/control  operations  are  compatible. 

5.2.3  Text  entry. 

a)  Adequate  display  capacity  is  provided  to  support  text  entry  and 

editing. 


b)  When  possible,  the  system  automatically  defaults  to  a  standard 
text  input  format. 

c)  When  users  can  define  text  entry  formats,  they  are  capable  of 
being  stored  for  future  use. 

d)  Frequently  used  text  segments  are  separately  stored  and  do  not 
require  keying  when  needed. 

e)  information  required  for  text  entry  or  editing,  such  as  user 
guidance  information,  is  separately  displayed  on  the  display  medium,  and 
is  distinct  from  entered  or  displayed  text. 

f)  As  required  by  the  system  and  the  user  task,  auditory  signals 
are  provided  to  alert  the  user  to  direct  attention  to  the  display. 

5.2.3. 1  Cursor  movement. 

a)  When  entering  or  editing  text,  users  are  able  to  freely  move 
the  cursor  within  a  displayed  page,  to  specify  items  for  change,  and  to 
make  changes  directly  to  the  text. 

b)  Users  are  able  to  move  cursors  by  specific  units  of  text,  such 
as  by  paragraph,  line,  page,  and  character. 

c)  Users  do  not  have  to  frequently  alter  hand  positions  between  a 
pointing  device  to  position  cursors  and  the  keyboard  to  edit  or  add  text. 

5.2.3.2  tSlLing. 

ri;  !  j  IKS  are  able  to  specify  units  of  text  in  editing  and  other 

contr.ji 


bi  Users  are  able  to  select  and  move  sections  of  text  within  a 

diXU'erjUt, 


r-  vt  specified  for  control  entry  is  highlighted  or  otherwise 
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Checklist 


YES 


ND 


N/A 


indicated. 

d)  Easy  to  use  commands,  such  as  MOVE,  COPY,  and  DELETE,  for 
adding,  inserting,  or  deleting  text  segments  are  provided.  ROLL  and 
SCROLL  commands  refer  to  the  display  window  such  that  the  display 
window  appears  as  an  aperture  moving  over  stationary  text. 

e)  Editing  actions  are  reversible,  by  use  of  an  UNDO  function. 

f)  An  explicit  action  is  required  to  delete  sections  of  text. 

a)  Easy  means  for  users  to  specify  page  formats  is  provided. 

b)  The  system  provides  automatic  line  breaks  when  entered  text 
reaches  right  margins. 

c)  Automatic  word-wrap  is  provided. 

d)  Hyphenation  only  occurs  by  user  specification. 

e)  Page  breaks  are  under  the  control  of  the  user. 

f)  Entered  text  is  left  justified,  and  consistent  spacing  provided 
between  words,  unless  otherwise  specified  by  the  user. 

g)  Natural  units  of  text  are  provided. 

h)  Control  entries  which  are  displayed  in  text  are  distinguishable 
from  the  main  text. 

5.2.3-31  Pagination. 

a)  The  system  provides  automatic  pagination,  while  providing  the 
user  the  capability  to  specify  page  size. 

b'  If  automatic  repagination  is  not  provided,  a  warning  message 

is  p'csoniod  to  the  user, 

c)  Users  are  able  to  override  automatic  pagination  and  be  able  to 
pecTy  r.i.cjc  nui'nbers,  at  any  point  in  a  document. 

d)  The  system  automatically  increments  pages  at  any  point  after 
iee  i!  -.p*  ■.ifie-'  a  b‘-ginning  page  number. 
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Chockiisl 


YES 


N/A 


ro 


e)  Insertinr]  text  into  a  paginated  document  does  not  result  in  loss 
of  information. 

5. 2. 3. 4  Searching  toxt. 


a)  Ctiaracter  string  seatch  capability  is  provided  and 
auioniatically  locates  ttie'  cursor  at  the  occurrence  of  any  matched 
string.',. 


h)  I.Jppor  and  lov;or  case  is  ignored,  unless  specified  by  the  user. 

c)  A  global  search  and  replace  capability  is  provided. 

d)  Users  are  able  to  specify  upper  and  lower  case  matches  in 
global  search  and  replace  transactions. 

5. 2. 3. 5  Priirting. 

a)  A  display  mode  is  provided  which  displays  text  exactly  as  it 
will  f)'}  prinhxl. 


tj)  Printout  options  are  selectable  as  well  as  portions  of  text  to  be 

pnnt'.'d. 

c)  The  siaiirs  of  selectable  printout  options  is  available  to  the 
user  for  review  and  change. 

d)  Printout  status  informa'ion  is  dis’played  for  the  user. 


1  f;  r, 


a)  A  uaiquo,  stanaara  symbol  is  used  for  prompting  data  entry. 


b)  Hardcopy  forms  that  are  used  for  inputting,  updating,  or 
correcting  data  corresponds  to  screen  display  in  terms  of  order  of  entry, 

aata  grouping,  etc. 

c)  Where  no  source  documents  or  forms  exist  to  support  data 
entry,  data  fields  are  logically  grouped,  by  sequence  and  frequency  of 
use.  importance,  and  functional  associations. 

d)  When  entry  of  data  in  a  field  is  deferred  or  orniited,  the  system 
identifiws  the  field  by  highlighting  or  other  means  and  the  user  is 
'oformed  that  data  have  not  been  input. 

5. 2. 4, 1.1  Field  definition/delimiters. 

a)  Separate  data  Items  are  entered  without  the  need  fer  user  input 
of  separators  or  delimiters,  if  a  user  input  field  delimiter  is  needed,  a 
standard  symbol,  such  as  a  slash  (/)  is  used. 

b)  Special  characters  is  used  to  delineate  data  fields  and  data  field 

i'mqihs. 


c)  Data  entry  by  overwriting  a  set  of  characters  within  a  field  is 
avoided,  deletion, 'insertion  is  used  instead. 

d)  Users  do  not  tiave  to  remove  unused  underscores  or  otherwise 
enter  keystrokes  for  each  position  within  a  variable  length  entry  area. 

c)  Optional  vs.  required  data  entries  within  fields  on  input  forms 

are  distinct. 


2  4  1 


.Data  f'pid 


a)  Data  fields  are  labeled  consistently,  uniquely  and  adjacent  m 
ttre  data  input  area, 

h'  l.abels  for  data  fields  are  visually  distinctive,  from  data 
;  u-  ri.  pr  nip's,  and  other  information  of  displays. 

r.i  Formats  consistent. 


Checklist 


YES 


^D 


N/A 


d)  Data  field  labels  appear  in  upper  case  only,  while  entered  text 
may  app!!.ir  m  ^oth  upper  and  lower  case. 

e)  Ui  iioss  required  for  user  form  design,  field  labels  are  not 

editable  by  users, 

t)  Field  labels  terminate  with  a  special  symbol  to  signify  data 

entry  point 

g')  Data  fields  are  descriptively  worded  by  whole  words 
(preferred)  or  predefined  terms,  codes,  or  abbreviations  (acceptable). 

h)  Arbitrary  codes,  such  as  numbering  schemes,  are  avoided. 

5. 2. 4. 1.2.1  Units  of  measurement. 

a)  Wnen  units  of  measurement  are  consistent  within  a  field 
entry,  fit-ld  labels  identify  the  appropriate  units. 

D)  units  of  measurement  familiar  to  the  user  are  used. 

c)  Where  alternative  units  of  measurement  may  be  required  for 
input,  an  associated  field  or  field  modifier  is  provided. 

d)  The  user  does  not  have  to  transform  units  at  lime  of  data  entry. 

5. 2. 4. 2  Cursor  positioning. 

3;  Wtien  a  new  or  blank  form  is  presented  to  the  user,  the  cursor 
is  positiuru.-d  at  the  beginning  of  the  first  entry  field. 

b)  U  ;  cursor  positioning  is  minimized. 

Wi  *jre  thr}  number  of  fields  is  limited,  screen  traversal 
disian,  H!-:  :nort.  and  when  data  fields  will  be  accessed  sequentially, 
oxp!:Cit  mbrjirv;  u,  available  for  advancing  to  subsequent  fields. 

■  b  11'  !,Mr,!'i,catcd  forms  with  many  fields,  or  when  field  entry 
will  bv  !■  .  ;  ;  vUiu:  ihlo,  direct  pointing  devices,  such  as  mouse  or 
iighip.'u,  :  tor  selecting  fields. 


r,  not  able  to  position  the  cursor  within  protected 
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Checklist 

YES 

N/A 

- 

a)  When  entering  logically  related  items,  the  system  only 
requires  entry  of  information  which  changes  through  subsequent  forms, 
afid  this  information  is  located  at  the  end  of  the  form  filling  transaction. 

b)  Users  are  able  to  REVIEW,  CANCEL,  or  BACKUP  to  any  field 
and  change  any  item  prior  to  taking  a  final  ENTER  action. 

c)  For  variable  length  field  entries,  automatic  justification  of  the 
input  data  is  provided. 

d)  Unless  otherwise  required  by  processing  or  display 
requirements,  alphanumeric  input  is  left  justified,  and  numeric  input  is 
right  justified  for  integer  data  or  decimal  point  justified  for  decimal 
data. 

e)  Users  do  not  have  to  provide  a  keystroke  for  every  character 
space  reserved  by  the  field. 

i 

I 

! 

i 

j 

i 

1 

1 
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Checklist 


YES 


N/A 


N3 


5.2.5  Tabular  data  entry. 

a)  Where  sets  of  data  must  be  entered  sequentially  or  where  data 
is  keyed  row  by  row,  a  tabular  display  format  is  used. 


b)  Information  input  is  automatically  justified,  without  the  user 
having  to  insert  blank/nuli  characters. 


c)  Numeric  data  is  automatically  right,  or  decimal  point, 

]us!ili(.‘d. 

d)  Users  do  not  have  to  input  leading  or  trailing  zeros. 

e)  Numeric  values  are  displayed  to  level  of  significance  required 
of  the  data  regardless  of  the  value  of  individual  input  data. 

f)  Every  fifth  row  of  a  table  is  separated  by  a  blank  line  or  other 
delimiter. 


5.2.5. 1  Cursor  positioning/tabbing.  Users  is  able  to  tab  to  adjacent 
fields,  across  rows  or  columns. 

5.2.5.2  Labels. 

a)  Each  row  and  column  is  uniquely  and  informatively  labeled  and 
is  visually  distinct  from  data  entries. 

b)  Where  more  data  fields  exist  than  can  be  displayed  on  a  single 
display  page,  row  and  column  labels  remain  along  the  top  (or  bottom) 
and  left  (or  right)  edges  of  the  display. 

c)  Labels  do  not  scroll  off  the  visible  portion  of  the  display. 
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Checklist 


YES 


N/A 


a)  When  entering  and  manipulating  graphic  data,  pointing  devices 
is  used  rather  than  keyboards. 

b)  When  pointing  is  used  as  medium  for  graphic  input  and 
manipulation,  system  control  uses  pointing  devices. 

c)  Easy  means  for  saving  and  loading  graphic  displays  is  provided. 

d)  Users  are  able  to  specify  graphic  display  names  and  to  review 
lile  catalogs  of  stored  graphics. 

e)  When  specified  by  the  user,  the  system  provides  automatic 
object  alignment  to  an  invisible  rule  or  grid  structure.  The  user  does 
not  have  to  align  and  space  separate  "objects". 

f)  Where  possible,  the  system  validates  graphic  data  input. 

5. 2.6.1  Cursors/pointer  positioning. 

a)  Graphics  display  cursors  are  distinctive  and  have  a  point 
which  can  be  used  to  select/manipulate  small  graphic  objects. 

b)  Cursors  are  easy  to  position  and  simple  to  point  to  display 
elements  or  locations. 

c)  Graphic  data  entry  cursors  have  a  movement  (pointing) 
'^mponent  and  an  activation  component;  the  movement  component 
positions  the  cursor  while  the  activation  component  activates  the  cursor 
pointing  location  in  order  to  manipulate  a  display  element. 


5. 2. 6. 2  Drawing. 

a)  Automatic  grid  alignment  for  drawn  objects  is  available  to 
users  at  their  request.  Users  are  able  to  specify  grid  inten/als. 

b)  Users  are  able  to  scale  object  sizes,  by  enlarging  or  reducing. 

c)  Users  are  able  to  fill  enclosed  areas  with  colors  or  patterns. 

d)  Users  are  able  to  select  automatic  figure  completion. 

e)  Where  possible,  general  computer  models  that  will  allow 
users  to  generate  specific  from  general  drawings  are  provided. 


Checklist 


YES 


hD 


N/A 


{;  Critical  or  difficult  grapnic  arawing  tasks  are  supported  by  a 
"zoofTiing"  funotioa  to  enlarge  critical  display  areas. 

5. 2. 6. 2. 1  Fiouro  aeneralion. 

a;  !  i  m  system  automatically  draws  lines  between  user  specified 
points  and  supports  the  drawing  of  rectangles,  arcs,  ovals  and  other 

figurtrs 

h'  Obiects  emerge  as  they  are  being  drawn. 

^  .'Sr-ss  are  able  to  constrain  line  drawing  to  exactly  verticn!  or 

hofizonta!. 

d)  For  precise  drawing,  users  are  able  to  specify  their  geometric 

relations  to  ottior  litres. 

e;  Aiternate  methods  are  provided  for  drawing  objects. 

f)  l.isers  are  able  to  copy,  rotate,  and  vertically  or  horizontally 

mirro!  irTt,:i;;e  oh|ects. 

5.2. 6. 2. 2  Grouping/mergina  objects. 

a;  i'ne  system  automatically  merges  objects  and  assign 
precodence  to  objects. 

b)  Thu  system  provides  means  to  group  separate  objects  into  a 

single,  qt  jitpird  ob|OCt. 

c)  VVfiure  separately  drawn  lines  must  connect  at  terminal 
points,  -1'.'  ‘-ysfem  automatically  makes  the  connections. 

5-2  5  h  FCaoihc  obiects.  elements  and  attributes. 

r!'  s  display  elements  are  selectable  by  the  user  for 
manip..'  i  !  :n  and  element  attributes  are  selectable  and  editable  by 
poinim  ;  •  :v!  '  -oG  oting  from  di.splayed  examples. 

a  aiinbutcs  are  displayed  as  selected,  and  are  not 
US  ’  ■  '  '■  '  '  by  codes  or  other  means. 

:  S'l  suiection/editing  methods  are  consistent. 

i  ■  '  :  a'.  0,  selected  graphic  elements  are  highlighted  or 
otfi'sv.  .(  f;<;  :!  to  the  user. 
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Checklist 


YES 


N/A 


hD 


5.2.6.4  Plotting  data. 


I  a)  When  complex  graphic  data  must  be  entered  quickly,  computer 

aids  are  provided. 


b)  The  system/software  supports  automatic  plotting  of  stored 

data. 

c)  Where  frequently  used  or  constrained  graphic  formats  exist, 
the  system  provides  graphic  templates  to  the  user. 


d)  The  system  provides  for  automatic  scaling  of  graphic  data  and 
users  are  able  to  modify  system  generated  scales. 

e)  When  graphic  data  can  be  derived  from  data  already  in  the 
computer,  machine  aids  are  provided. 


ND  N/A 


5.2.7. 1 


a)  The  user  is  able  to  obtain  a  paper  copy  of  the  contents  of 
alphanumeric  or  graphic  displays. 

b)  If  information  is  printed  remotely,  print  status  messages  are 
displayed  and  screen  contents  are  not  changed  as  a  result  of  the  print 
operation. 

c)  In  repetitive  data  entry  task,  inputs  are  validated  at  the  time 
of  each  transaction. 

d)  For  novice  users,  the  system  provides  optional  item-by-item 
data  validation  within  a  multiple-entry  transaction. 

5. 2. 7.2  System  validation. 


a)  Where  possible,  automatic  data  validation  to  check  data  for 
correct  format  is  provided. 

b)  CoMCCt  data  entries  are  accepted  and  processed  properly  by 
the  computer  without  need  for  user  involvement  to  proceed. 

c)  Where  possible,  when  a  data  or  command  entry  does  not  meet 
validation  logic,  a  cautionary  message  is  displayed  asking  the  user  tc 
confirm  data  entry. 


d)  If  data  validation  detects  a  probable  error,  an  error  message  is 
displayed  at  the  completion  of  a  field/data  entry,  without  interrupting  an 
ongoing  transaction. 
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Checklist 


YES 


ND 


N/A 


5.3.1  general. 

5. 3. 1.1  Display  of  information. 

a)  Inlormaiion  density  is  minimized  in  displays  used  for  critical 
task  sequences. 

b)  For  critical  information,  a  minimum  of  one  character  space  is 
left  blank  vertically  above  and  below  critical  information,  with  a 
minimum  of  two  character  spaces  left  blank  horizonialiy  before  and 
after. 


c)  Whenever  possible,  users  are  aolc  *o  see  the  whole  page  with 
which  they  are  working. 

d)  Data  needed  for  a  transaction  is  displayed  in  a  directly  usable 
form,  and  only  essential  data  is  displayed. 

e)  Users  are  able  to  control  the  amount,  format,  and  complexity 
of  displayed  data,  as  necessary  to  meet  task  requirements. 

f)  Users  are  able  to  obtain  a  papei  copy  of  the  exact  contents  of 
alphanumeric  or  digital  graphic  display  in  systems  where  mass  storage 
is  limited,  mass  stored  data  can  be  lost  by  power  interruption,  or  where 
record  keeping  is  required. 

g)  t.^sk  performance  requires  or  implies  the  need  to  assess 
currency  of  information,  displays  are  annotated  with  date-time 
information, 

5.3.1  2  CQnsislgncy/slandardiz.aliOIl- 

a)  Data  is  displayed  consistently  in  word  choice,  formal,  and 
ba.sic  style,  a.-vJ  wilfcn  standards  and  conventions  familiar  to  users. 

b.)  Data,  display  is  standardized  within  applications  and  across 
transactujris. 


5.3.1  3 

r, ,  I  St,’  wording  of  displayed  data  and  labels  Incorporate  familiar 
terms  and  tni:  t  isK  oriented  language  of  the  users. 

bl  T  n.,>  US"  of  unfamiliar  language  of  designers  and  programmers 
is  avoxb'd 
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Checklist 


YES 


N3 


N/A 


c)  Consistent  wording  is  provided  for  displays,  data  and  labels. 

d)  Consistent  grammatical  structure  for  data  and  labels  within 
and  across  displays  is  provided. 

6. 3. 1.4  Labeling. 

a)  Each  individual  data  group,  message,  or  frame  contains  a 
distinct,  unique,  and  descriptive  label. 

b)  Display  frame  labels  are  an  alphanumeric  code,  or  an 
abbreviation  which  is  prominently  displayed  and  is  short  enough  (3-7 
characters)  or  meaningful  enough  to  be  learned  and  remembered  easily. 

c)  Labels  are  highlighted  or  otherwise  emphasized.  The  technique 
used  IS  easily  distinguished  from  that  used  to  highlight  or  code 
emergency  or  critical  messages. 

d)  Labels  are  descriptively,  consistently  and  distinctly  worded. 

e)  Label  locations  and  formats  are  consistent. 

5.3.1 .5  Format. 

a)  A  consistent  organization  of  display  features  among  displays  is 
adopted. 

b)  Different  elements  of  display  formats  are  distinctive  within  a 
display,  but  is  consistent  across  displays. 

s)  Blank  space  is  used  to  structure  a  display. 

d)  Groups  of  information  is  separated  by  blanks,  lines,  color 
coding,  or  other  visually  distinctive  means. 

5. 3. 1.5.1  Layout. 

a)  Display  windows  are  labeled  at  the  top  wun  a  title  or  header 
wnicli  describes  the  contents  or  purpose  of  the  display. 


b)  At  least  one  blank  line  between  the  title  and  the  body  of  the 
(iisolay  IS  provided. 

c)  Where  control  is  exerted  via  keyboard,  the  last  several  linos 
at  the  bottom  of  every  display  is  reserved  for  status  and  error  messages, 

prompts,  or  command  entry. 


d)  Where  users  must  analyze  sets  of  data  to  discern  similarities. 


Checklist 

differences,  irerids.  and  relationships,  displays  are  formatted  so  that  the 
data  are  grouped  to  facilitate  analysis  and  comparison. 


YES 


ND 


N/A 


e)  Data  fields  to  be  compared  on  a  character  by  character  basis  is 
positioned  one  above  the  other. 


f)  Where  possible,  data  is  grouped  by  sequence,  function, 
importance,  or  frequency  of  use,  or  by  other  means  such  as  alphabetic  or 

chronology. 


g)  Context  for  displayed  data  is  provided. 


h)  Visually  distinctive  data  fields  are  provided. 


5.3. 1.5. 2  Muitipaqe  displays. 

a)  When  a  display  contains  too  much  data  for  presentation  in  a 
single  frame,  the  data  is  partitioned  into  separately  displayable  pages. 

b)  Related  data  appear  on  the  same  page  and  relations  among  data 
sets  appear  in  an  integrated  display  rather  than  partitioned  into  separate 
windows. 


c)  Each  page  is  labeled  to  show  its  relation  to  the  others. 
5  3.1 .6  Coding. 


a)  Coding  is  employed  to  differentiate  between  items  of 
information,  to  call  the  user's  attention  to  changes  in  the  state  of  the 
system,  and  to  indicate  important,  hazardous,  or  critical  information 
which  requires  user  action. 


b)  Coding  by  data  category  is  provided  where  a  user  must 
distinguish  rapidly  among  different  categories  of  displayed  data  that  are 
distributed  in  an  irregular  way  on  the  display. 

c)  Meaningful  codes  are  used  rather  than  arbitrary  codes. 


d)  Coding  is  consistent  across  displays. 


e)  Codes  assigned  special  meaning  in  a  display  is  defined  at  the 
bottom  of  the  display  and  replicates  the  code  being  defined. 

5. 3. 1.6.1  Alphanumeric  coding. 

a)  Alphanumeric  coding  may  be  used  to  supplement  other  coding 
schemes  ,  but  is  not  used  as  the  sole  means  to  call  attention  to  important 
or  critical  information. 
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Checklist 


YES 


ND 


N/A 


b)  Aiphanurneric  codes  display  all  letters  consistently  in  either 
upper  or  lower  case. 

c)  When  short  alphanumeric  codes  combine  both  letters  and 
numbers,  letters  and  numbers  are  grouped  together  rather  than 
interspersing  letters  with  numbers. 

d)  Arbitrary  alphanumeric  codes  that  must  be  recalled  by  the 
user  are  no  longer  than  four  or  five  characters. 

5. 3. 1.6. 2  Auditory  coding. 

a)  Auditory  coding  signals  are  used  to  alert  an  operator  to  critical 
conditions  or  operations,  as  a  means  of  supplementing  visual  display  or 
as  an  alternative  means  of  information  presen:  on  where  visual  display 
is  not  feasible,  and  as  a  means  to  provide  feedback  for  control  actuation, 
data  entry,  or  completion  of  timing  cycles  and  sequences. 

b)  Noncritical  auditory  signals  are  capable  of  being  turned  off  at 
the  discretion  of  the  user. 

c)  A  simple,  consistent  means  of  acknowledging  and  turning  off 
alarm  signals  is  provided. 

d)  Auditory  signals  are  provided  when  computer  response  to  a 
user  request  is  greater  than  1,5  seconds. 

e)  Signals  are  intermittent  in  nature  to  allow  the  user  sufficient 
time  to  respond.  Auditory  signals  are  distinctive  in  intensity  and  pitch, 

f)  The  number  of  signals  to  be  identified  does  not  exceed  four. 

g)  The  intensity,  duration,  and  source  location  of  the  signal  is 
selected  to  be  compatible  with  the  acoustical  environment  of  the  intended 
receiver  as  well  as  with  the  requirements  of  other  personnel  in  the 
Signal  area, 

h)  For  auditory  displays  with  voice  output,  different  voices  are 
used  to  distinguish  different  categories  of  data. 

i)  If  computer-generated  speech  output  is  used  for  auditory 
display,  a  special  alerting  signal  is  provided  to  distinguish  them  from 
routine  voice  messages. 

5  3.1.6.3  Brightness  intensity  coding. 


a)  Brightness  intensity  coding  may  be  used  to  differentiate 
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between  adjacent  items  of  information  or  to  code  two  to  three  staie 
conditions. 

b) Brightness  coding  has  only  one  meaning. 

c)  Each  level  of  brightness  coding  is  separated  from  the  next 
nearest  level  by  a  2:1  ratio  and  discriminates  only  between  two 
categories:  bright  and  dim. 

d)  "Inverse  video"  may  be  used  to  highlight  critical  items  that 
require  user  attention.  When  used,  brightness  inversion  is  reserved 
exclusively  for  that  purpose  and  not  used  for  general  highlighting. 

5.3.1 .6.4  Color  codino. 

a)  Color  coding,  where  appropriate,  is  used  to  differentiate 
between  classes  of  information  in  complex,  dense,  and  critical  displays. 

b)  The  icilowing  reserved  color  meanings  are  used; 

RED  is  used  to  indicate  conditions  such  as  "no-go",  "error", 

"failure",  "malfunction",  etc. 

FLji\SHING  red  is  used  only  to  denote  emergency  conditions 
requiring  immediate  operator  action,  or  to  avert  personnel 
injury,  equipment  damage,  or  both. 

YELLOW  is  used  to  indicate  marginal  conditions  or  to  alert 
situations  where  caution,  recheck,  or  unexpected  delay  is 
necessary. 

GREEN  is  used  to  indicate  that  monitored  equipment/processes  are 
within  tolerance  or  a  condition  is  satisfactory  and  that  it  is  all 
right  to  proceed  with  an  operation  or  transaction. 

WHITE  IS  used  to  indicate  system  conditions  that  do  not  have 
operabiiily  or  safety  implications,  but  indicate  alternative 
functions. 

BLUE  may  be  used  as  an  advisory  color,  preferential  use  of  blue 

is  avoided 

c;  Color  may  be  used  to  identify  data  categories  when  it  does  not 
conf'ict  '.'.sL'  color  coding  conventions  and  does  not  conflict  with  the 

color  associations  specified  above. 

c*.)  Use  o!  color  as  a  formatting  code  is  subordinate  to  other 

mo'hod::, 

p, 
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e)  Color  coding  is  redundant  to  some  other  means  of  coding  such  as 
symbology:  coding  only  by  coloi  is  avoided. 

f)  Color  coding  is  not  used  if  the  information  will  be  accessed 
from  monocromatic  displays  or  hardcopy  printouts,  or  if  users  may  be 
deficient  in  color  perception. 

g)  Colors  is  easily  discriminable  and  color  coding  is  used 
conservatively.  Each  color  represents  only  one  category  of  displayed 

data. 

h)  Brighter  or  more  saturated  colors  is  used  when  it  is  necessary 
to  draw  a  users  attention  to  critical  data. 

5. 3. 1.6.5  Flash  coding. 

a)  Flash  coding  is  only  used  to  display  an  urgent  need  for  user 
attention. 

b)  No  more  than  two  levels  of  flash  coding  is  used. 

c)  Flash  rate  in  the  range  of  3  to  5  Hz  is  used  with  equal  "on"  and 
"off"  intervals.  If  two  flash  coding  levels  are  used,  the  second  flashes  at 
less  than  2  Hz. 

d)  When  a  displayed  item  is  blink  coded,  a  flashing  ma.'ker 
symbol  is  used  rather  than  blinking  the  item  itseii. 

e)  Event  acknowledgment  or  flash  suppression  keys  is  provided. 

5.3. 1.6. 6  Line  coding. 

a)  Line  coding  by  color,  including  variation  in  line  type  and  line 
width  may  be  used. 

b)  Underlining  may  be  used  to  indicate  unusual  values,  errors  in 
entry,  and  data  changes. 

c)  Underlining  rather  than  overlining  is  used. 

d)  Coding  by  line  length  may  be  used  for  applications  involving 
spatial  categorization  in  a  single  dimension. 

e)  Coding  by  line  direction  may  be  used  for  applications  involving 
spatial  categorization  in  two  dimensions. 

5.3  1 .6.7  Patfern/location  codina.  Pattern  and  location  coding  may  he 

_ i 
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_ I 

A  181 


Checklist 

used  10  re:.;  soarcli  enie  by  restricting  the  area  to  be  searched  to 
prescribed  segments. 


ro 


N/A 


5.3. 1.6. 8  Shape^symbol  coding. 

a)  Symbol  coding  is  used  to  enhance  the  transfer  of  information. 


b)  Symbols  are  analogs  of  the  event  or  system  elements  they 
represent,  be  in  general  use  and  well-known  to  the  users,  and  be  based 
on  established  standards  or  conventional  meanings. 

c)  Symbol  heights  do  not  differ  more  than  three  sizes. 


d)  Special  symbols,  such  as  asterisks,  arrows,  etc.,  may  be  used 
to  draw  attention  to  selected  items  in  alphanumeric  displays. 


e)  Use  of  special  symbols  is  consistent  and  their  meanings  unique. 

f)  Shape  codes  using  more  than  15  different  shapes  is  avoided. 
Component  shapes  may  be  used  in  combination. 


5.3. 1.6. 3  Size  coding.  When  used,  size  coding  does  not  exceed  3  sizes. 
For  size  coding,  a  larger  symbol  is  at  least  1 .5  times  the  height  of  the 
next  smaller  symbol. 
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b)  When  a  user  may  need  to  view  data  relations,  pictures, 
diagrams,  maps,  etc.,  in  detail,  a  zooming  capability  is  provided. 

c)  VV'i>  n  a  display  iias  been  expanded  by  zooming  from  its  normal 
coverage,  a  scale  indicator  of  the  expansion  is  provided. 

d)  Panning  and  zooming  functions  are  integrated  with  scales  and 
other  overlayed  data,  such  as  scaled  marks,  range  vectors,  etc. 

e)  An  ove-^iew  position  of  an  expanded  section  of  a  display  is 
provided  as  a  user  reference  to  position  within  a  display. 

5. 3. 2. 2. 3  liilormalion  suppression. 

a)  Temporary  suppression  of  displayed  data  may  be  provided 
when  information  is  not  needed  to  support  task  conduct.  Information 
suppression  is  indicated  on  the  display. 

b)  An  indication  of  changes  of  significant  suppressed  data  is 
provided. 

('.)  i  isers  are  provided  with  means  to  quickly  restore  suppressed 
data  to  the  display. 

5. 3. 2.3  Labelina  and  markino  information. 

a)  When  a  user  can  select/manipulate  data  displays,  each  display 
has  an  identifying  label  and  other  identifying  information  to  support 
display  control  and  data  access. 

b)  Identifying  labels  are  located  in  a  prominent  and  consistent 
location  and  are  unique,  short  and  meaningful. 

c)  Annotating  displays  of  continued  data  is  provided. 

d)  Paging  vs.  scrolling  labels  is  consistently  distinct  and 

unambiguous 

I;)  I  abon'ig  for  display  paging  is  referred  to  in  functional  terms. 

f)  W'uin  lists  of  numbered  items  exceed  one  display  page,  items 
are  numi'ei’ d  ooiofinuousiy  in  relation  to  the  first  item  on  the  first  page. 


coy 


.r.ust  accuraiely  leaoi  changing  aata,  the  data  is 
displayed  long  enough  to  read  to  the  level  of  precision  required. 
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b)  Rate  of  display  regeneration  does  not  exceed  user  perceptual 
and  information  processing  capabilities. 

c)  Changing  alphanumeric  data  which  must  be  reliably  or 
aocorately  read  are  not  updated  more  often  than  once  per  second. 

ri)  When  the  information  displayed  is  to  be  considered  real  time, 
ciranging  values  which  are  used  to  identify  rate  of  change  or  to  read  gross 
values  are  not  updated  faster  than  5  limes  per  second,  nor  slower  than  2 
times  per  second. 

5. 3. 2. 4.1  Usen'system  control. 

a)  Unless  directed  by  task,  system,  or  mission  requirements, 
users  are  able  to  initiate  display  regeneration. 

b)  The  rate  of  information  update  is  controllable  by  the  user  and 
is  determined  by  the  use  to  be  made  of  the  data. 

c)  When  data  is  changed  via  automatic  processing,  data  updates 
are  temporarily  highlighted  or  otherwise  marked. 

5. 3. 2. 4. 2  Freeze  frame. 

a)  When  displayed  data  are  automatically  updated,  users  are  able 
to  "freeze"  the  display  to  examine  changed  data  more  deliberately. 

b)  When  frozen,  the  display  is  clearly  labeled,  and  users  are 
warned  if  some  significant  data  change  has  occurred  due  to  subsequent 
processing  or  sensing. 

c)  When  resuming  update  after  display  freeze,  display  update 
resumes  at  the  current  real-time  point  unless  otherwise  specified  by 

the  user. 

.5  3.2.4  3  Data  extrapolation.  When  needed,  a  prediction  display 
extrapolating  dynamic  display  information  is  provided. 

_ 

_ 
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5.3.3  Voice  displays.  Voice  displays  may  be  used  to  supplement  visual 
displays  when  communication  flexibility  is  necessary,  when  coded  signal 
meanings  are  numerous  or  may  be  forgotten,  for  presentation  of  complex 
directions  or  instructions,  when  ambient  noise  may  mask  simple  tonal 
signals  or  in  conjunction  with  tonal  signals,  and  for  presentation  of 
continuous  information  where  rate  of  change  is  low. 


YES 


NC 


5.3.3.1 


a)  Words  selected  is  appropriate  to  the  task/information 
presented,  concise,  and  intelligible. 

b)  Where  possible,  words  that  rhyme  and  may  confuse  message 
interpretation  are  not  part  of  the  spoken  lexicon,  or  are  not  presented 
within  the  same  message. 

c)  Use  of  slang  is  avoided. 

d)  Words  with  more  than  one  syllable  are  used. 

e)  Alphanumeric  data  is  presented  using  phonetic  alphabets. 

5. 3.3. 2  Presentation. 

a)  Spoken  messages  are  produced  in  the  form  of  the  "average 
talker",  in  an  American  English  accent  without  regional  dialects. 

b)  Speech  intensity  is  appropriate  to  the  expected  ambient  noise 
environment. 

c)  Within  a  typical  office  space  intensity  is  approximately  70  to 
75  dB  sound  pressure  level. 

d)  Signal  to  noise  ratios  is  at  least  5:1 . 

e)  Audio  signal  power  is  approximately  300  milliwatts  at  the 
listeners  ear. 

f)  Speech  signals  fail  within  the  range  of  200  to  6100  Hz. 

g)  Spoken  warning  messages  are  preceded  by  an  alerting  signal. 
Users  are  required  to  acknowledge  spoken  warning  signals. 

h)  Messages  are  brief,  informative,  and  to  the  point. 


N/A 
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5.3.4  Windows. 

a)  Window  overlays  may  be  provided  to  temporarily  add  data  to  a 
display,  or  as  a  means  to  control  or  display  divergent  information,  or  to 
segregate  and  control  separate  operations. 

b)  The  display  screen  is  capable  of  displaying  each  of  the  windows 
simultaneously,  in  either  a  tiled  or  overlapped  format,  as  requested  by 

the  user. 

c)  Windows  are  predefined  and  displayed  under  user  control,  as 
appropriate. 

d)  Window  overlays  are  nondestructive  and  do  not  permanently 
erase  overlayed  data. 

5.3.4. 1  Format. 

a)  Default  formats  represent  the  "configuration"  of  the 
information  to  be  displayed,  and  the  expectations  and  experience  of  the 
typical  user. 

b)  The  size  and  shape  of  the  initial  presentation  of  a  window  is 
consistent  with  it.s  contents. 

c)  Windows  v/hich  are  dedicated  to  command  entry  by  keyboard 
input  are  located  a.l  the  bottom  of  the  display  area. 

5. 3.4. 2  Labeling  and  identification. 

a)  Windows  must  be  visually  separated  from  each  other  and  from 
their  background,  preferably  by  borders  or  similar  demarcation. 

b)  Windows  are  identified  by  a  label  consistently  located  at  the 
top  of  the  window's  border.  Where  several  windows  can  be  displayed  at 
one  time,  active  windows  are  indicated  by  labeling  or  other  means,  and 
an  easy  means  of  shifting  among  windows  are  provided. 

c)  Labels  remain  on  the  screen  while  the  data  scrolls  beneath 

them. 

5. 3. 4. 3  Operation.  In  addition  to  the  guidelines  below,  the  guidelines  of 
Section  5.3.2  "Display  Control"  also  applies. 

a)  Windows  are  consistent  in  terms  of  command  syntax  and 
semantics.  Control  of  windov/  operations  are  consistent  throughout  the 
system. 


Checklist 

YES 

ND  I  N/A 

_ 

b)  As  appropriate  to  the  user  task,  windows  are  capable  of  the 
followiiiy  operatiuns:  scfolling/panning,  resizing,  moving,  hiding, 
activating,  deactivating,  copying  to/trom,  zooming  in/cut,  tabbing, 
undo-last 

c)  Fcr  text-c.'iy  windows  and  windows  used  for  scanning  data, 
window  Siting  is  constrained  such  that  the  smallest  possible  windov/  will 
contain  at  least  2  lines  of  tex*  /data. 

d)  Each  window  has  variable  line  widths  selectable  by  the  user. 

0)  Kevboatd  input  affects  only  the  active  window  designated  by 

the  uses 

f)  Users  are  able  to  specify  and  select  separate  data  windows  that 
will  share  a  single  display  frame.  The  system  provides  the  user  sevcial 
options  for  rrn'ving  between  active  windows. 

g)  Within  a  session,  the  system  keeps  track  of  the  windows  that 
are  open  and  display  them  as  a  menu. 

h)  .Automatically  updated  windows  have  display  freeze  capability. 
When  a  window  displays  automatically  updated  information,  the  user  has 
control  over  the  rate  at  which  autom''ticaIly  updated  screens  are 
scrolled  . 

i)  A  window  that  is  not  displayed  is  capable  of  sending  and 
receiving  information. 

5.3.4.4  Feedback. 

a)  The  system  provides  immediate  and  unambiguous  feedback 
concernino  which  active  window  is  being  acted  upon. 

b)  V  .'hen  the  user  is  communicating  with  a  closed  window,  the 
system  provides  feedback  designating  the  window{s)  involved. 

c)  If  v/indows  are  capable  of  different  modes,  the  system  provides 
immediate  an  j  unambiguous  feedback  concerning  which  mode  is  active. 

rj'i  Wt!<,-n  a  display  is  frozen,  the  syste'  provides  immediate  and 
unamhi' i  i '.  feedCack  and  the  user  is  prompted  to  return  to  automatic 

ijpd.a'r' 

o  i  A  warning  flag  is  displayed  to  alert  the  user  to  significant 
shang  i.n  r:;a:  time  data  chat  occurred  while  the  display  was  frozen. 

f  ‘  i  r'.er  l  equested  action  would  result  in  lost  or  damaged  data, 

_ 
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the  user  is  alerted  and  alternative  actions  recommended. 

g)  The  system  is  capable  of  alerting  the  user  to  critical 
ir.torma'  on  that  becomes  available  in  an  inactive  window. 

5.3.5  Data  fo'ms.  Forms  are  used  to  display  ■'elated  sets  of  data  in 
separately  labeled  fields. 

5.3.5. 1  Format. 

a)  Visually  distinctive  fields  are  provided. 

b)  When  forms  are  used  for  data  entry  as  well  as  for  the  data 
display,  the  format  for  data  display  is  compatible  with  whatever  format 
is  used  for  data  entry.  The  same  item  labels  and  ordering  for  both  is 

used. 

c)  The  ordering  and  layout  of  corresponding  fields  is  consistent 
among  displays. 

5. 3. 5. 2  Data  presentation. 

a)  Units  of  measurement  for  displayed  data  is  presented  in  the 
label  or  as  part  of  each  data  item. 

b)  Long  data  items  of  mixed  alphanumeric  characters  is  divided 
into  subgroups  of  three  or  four  characters  separated  by  a  blank  or  by 
other  symbol. 

c)  The  internal  format  of  frequently  used  data  fields  are 
consistent  from  one  display  to  another. 

d)  Blanks  (keyed  spaces)  are  distinguishable  fn-m  nulls  (no 
entry  at  all)  in  the  display  of  data  forms. 

5. 3. 5. 3  Data  field  labels.  Each  data  field  is  identified  with  a  display 
label  which  is  located  close  to  the  data  fields  they  identify. 
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5.3.6  1  EQiiUdt. 

a)  Cof.sistont  text  formats  are  provided  from  one  display  to 
anoihi'r.  and  conform  to  MiL-STD-490. 

b)  When  tables  and  graphs  are  associated  with  text,  they  are 
p!:i'.  .!;d  as  closely  as  possible  after  the  first  reference  within  the  text. 

c)  Information  is  placed  in  groups  to  permit  the  user  to  associate 
c:  compare  similar  classes  of  information. 

o  :  Grouping  may  be  accomplished  by  right  or  left  justification  of 
columns  to  establish  boundaries  of  greup  areas  spacing  between  groups, 
lines  between  group  areas  or  under  group  headings,  and  locating  items  to 
bn  comoared  character-by-character  in  subsequent  lines  on  the  display. 

o)  When  words  in  text  displays  are  abbreviated,  each 
abbreviation  is  defined  in  parentheses  following  its  first  appearance. 

f)  Critical  passagos/information  is  highlighted  by 
boiding/brightening,  color  coding  or  other  means.  Capitalisation  alone  is 
not  used. 

g)  Where  possible,  senes  of  related  text  is  displayed  in  a  list 
rather  than  as  continuous  text. 


5. 3. 6. 1.1  Lists. 

a)  Unless  dictated  by  the  amount  of  information  to  be  presented, 
or  where  information  is  to  be  composed,  lists  are  formatted  so  that  each 
item  starts  on  a  new  line. 

b)  When  a  single  item  in  a  list  continues  for  more  than  one  line, 
Items  are  marked  so  that  the  continuation  of  an  item  is  obvious. 

c)  When  listed  items  will  be  numbered,  Arabic  ra*her  than 
Rom.an  numerals  are  used. 

d)  Loading  zeroes  are  not  used  unless  required  for  clarity. 

0)  A  space  is  placed  after  every  third  cr  forth  a  git. 

f;  Item  numbers  begin  with  one,  not  zero.  Numbering  starts  with 
one  when  it  applies  to  counting  and  v/ilh  zerc  when  it  applies  to 
measurement. 
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g)  Lists  are  arranged  is  a  recognizable  order,  such  as 
cronologicai,  alphabetic,  sequential  functional,  or  importance 

h)  Where  a  lis»  is  displayed  in  multiple  columns,  the  items  are 
ordered  vertically  within  each  column. 

1)  For  a  long  list  extending  more  than  one  displayed  page,  the  last 
line  of  one  page  is  the  first  line  of  the  next  page. 

j)  For  hierarchical  lists,  such  as  outlines,  complete  identifiers 
are  used  rather  than  omitting  the  repeated  elements. 

k)  Identiiiers  are  not  indented,  but  titles  and  subtitles  are 
indented  so  that  their  structure  is  apparent. 

5. 3. 6. 1.2  Free  running  text. 

a)  Lengthy  textual  material  is  displayable  in  hardcopy  form 
rather  than  requiring  the  user  to  '•ead  it  on-lme. 

b)  When  a  user  must  continuously  read  text  on-line,  at  least  four 
lines  of  text  is  displayed  at  one  time. 

c)  Text  is  presented  in  mixed  upper  and  lowercase. 

d)  Text  is  formatted  in  a  few  wide  lines  containing  at  least  50 
characters  per  line,  rather  than  in  narrow  columns  of  many  short  lines. 

e)  Displayed  paragraphs  of  text  is  separated  by  at  least  one  blank 
line.  Paragraphs  are  numbered. 

f)  Consistent  spacing  between  the  words  of  displayed  text  is 
provided  with  left  justification  of  lines  and  ragged  right  margins. 

g)  Left  and  right  justification  may  be  used  it  it  can  be  achieved  by 
variable  spacing,  maintaining  constant  proportional  spacing  between  and 
within  words,  and  consistent  spacing  between  words  in  a  line. 

h)  Computer-generated  displays  of  textual  data,  messages,  or 
instructions  follow  design  conventions  for  printed  text. 


5.3  6.2 


a)  Text  displays  and  text  composed  for  user  guidance  is  concisely, 
clearly  and  simply  worded,  and  simple  sentence  structures  are  used. 

b)  Distinct  words  rather  than  contractions  or  combined  forms 
are  used  in  displayed  text. 
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c)  Where  possible,  affirmative  statements  rather  than  negative 
statcm(?nts  are  used,  and  sentences  are  composed  in  the  active  rather 

than  passive  voice, 

d)  When  a  sentence  describes  a  sequence  of  events,  it  is  phrased 
in  that  order. 

e)  Use  of  hyphenation  is  minimized  and  conventional  punctuation 

is  used. 

5. 3. 6. 3  Display  control. 


a)  When  the  user  is  scrolling  vertically  through  text,  the  present 
and  end  locations  are  displayed  on  the  viewable  portion  of  the  display. 

b)  Speed  of  text  display  is  controllable  and  does  not  exceed  the 
users  normal  reading  speed. 
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5.3.7  Ta^.!£S. 

5. 3. 7.1  Format. 

a)  In  tables  with  many  rows  or  columns,  a  blank  line,  dots,  or 
other  distinctive  features  are  inserted  after  every  third  to  fifth  row  or 
column.  The  columns  in  a  table  are  separated  by  blank  spaces,  or  by 
some  other  distinctive  feature. 

b)  Tabular  data  is  organized  in  a  consistent,  recognizable  pattern. 
Tabular  data  is  displayed  in  a  left-to-right,  top-to-bottom  array. 

c)  When  tabular  data  extend  over  one  page  vertically,  the 
columns  are  labeled  identically  on  each  page. 

d)  Tabular  data  does  not  extend  horizontally  over  more  than  one 

page. 

e)  Consistent  spacing  within  a  table,  and  from  one  table  to 
another,  is  maintained. 

a)  Data  are  presented  to  the  operator  in  a  readily  usable  and 
readable  format. 

b)  Requirements  for  transposing,  computing,  interpolating,  or 
mentally  translating  into  other  units  or  numerical  basis  is  avoided. 

c)  Columns  of  numeric  data  are  justified  with  respect  to  a  fixed 
decimal  point.  If  there  is  no  decimal  point,  then  numbers  are 

riylii  justified. 

d)  In  presenting  decimal  numbers,  trailing  zeroes  are  presented 
to  the  level  of  significance  of  the  number. 

e)  For  hierarchical  lists  with  compound  numbers,  complete 
numbers  are  displayed. 

5.3.71.2  Alphanumeric  data. 

a)  When  five  or  more  alphanumerics  are  displayed,  without  a 
precedent  grouping  organization,  characters  are  grouped  in  blocks  of 
three  to  four  characters.  If  a  series  is  to  be  10  units,  then  its  structure 
has  distinct  groups  of  3,  4,  3.  Groups  are  separated  by  a  minimum  of 

one  blank  character. 


b)  When  grouping  alphabetic  characters,  acronyms  or 
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abbreviations  arc  used  in  preference  to  randomly  selected  characters 
that  have  little  relevance  to  the  system. 


c)  Complex  coding  systems  use  a  combination  of  alpha  and 
numeric  designators  and  grouping  is  applied. 


d)  Columns  of  alphabetic  data  is  left  justified. 
5. 3. 7. 1.3  Reference  tables. 


a)  When  tables  are  used  for  reference,  items  are  located  in  the 
left  column,  and  display  the  material  most  relevant  for  user  response  in 
the  next  adjacent  column.  Associated  but  less  significant  material  is 
displayed  in  columns  further  to  the  right. 


b)  Alt  displayed  data  necessary  to  support  a  user  activity  or 
sequence  of  activities  is  grouped  together. 


c)  When  data  fields  contain  a  naturally  occurring  order,  such 
order  is  reflected  in  the  organization  of  the  field. 

5  3.7.1  4  Data  comparisons.  A  tabular  format  for  data  display  is  used 
when  information  handling  requires  detailed  comparison  of  ordered  sets 
of  data.  Where  data  items  must  be  compared  on  a 
character-by-character  basis,  data  are  vertically  structured. 

5.3.7.2  Labeling/identifvina  data. 

a)  Each  individual  field  is  labeled.  The  user  does  not  have  to  rely 
on  contextual  clues  alone  to  identify  a  field. 

b)  Table  row  and  column  labels  are  presented  in  terms  familiar 
to  the  user. 

c)  Labeling  units  of  measurement  are  part  of  column  labels,  or 
placed  after  the  first  row  or  column  data  entry. 
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a)  Graphics  displays  are  used  when  displaying  data  showing 
relations  in  space  or  time,  when  users  must  quickly  scan  and  compare 
related  sets  of  data,  or  when  users  must  monitor  changing  data. 


b)  Consistent  logic,  standard  formats,  and  labeling  are  provided 
each  method  of  graphic  presentation. 


c)  Graphically  displayed  information  is  limited  to  user 
information  needs  and  task  requirements. 


d)  Critical  data  is  highlighted. 

e)  When  needed  to  view  graphics,  pictures,  diagrams,  or  maps  in 
detail,  zooming  capability  is  provided. 

f)  When  a  display  has  been  expanded  from  its  normal  coverage,  a 
graphic  indicator  of  the  position  in  the  overall  display  of  the  visible 
section  is  provided. 

g)  A  scale  is  provided  for  maps  and  related  displays. 

h)  When  on-line  graphic  displays  must  be  printed,  users  are 
able  to  display  the  material  exactly  as  it  will  appear  in  the  printed 
output. 

5.3.8. 1  Format. 

a)  Label  formats  are  consistent. 

b)  As  needed  to  support  user  tasks,  reference  indices,  baselines 
and  text  annotations  are  included  in  graphic  displays. 

c;  Textual  data  annotation  is  provided  where  precise  information 
is  required. 

d)  Normal  orientation  for  labels  is  used. 

5. 3. 8. 2  Coding  and  symbology. 

a)  Symbol  meanings  are  standard  and  look  like  the  objects  or 
processes  they  represent. 

b)  When  used,  simple  texture  codes  are  used  rather  than 
elaborate  patterns. 

c)  Where  possible,  the  movement  of  data  elements  under 
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computer  control  has  an  animation  quality. 

d)  Where  sequential  relations  between  display  elements  requires 
highlighting,  animation  may  be  used. 

5.3.8.3  Curves  and  line  graphs. 

a)  Curves  and  line  graphs  are  used  for  displaying  relations 
between  two  continuous  variables,  as  in  showing  data  changes  over  time. 

b)  Unless  required,  use  of  three-dimensional  scales  is  avoided. 

c)  Curve  and  line  graphs  convey  enough  information  to  allow  the 
reader  to  interpret  the  data  without  referring  to  additional  sources. 

d)  When  curves  must  be  compared,  they  are  displayed  in  one 
combined  graph. 

e)  Figure  and  title  elements  are  clearly  identified. 

5.3. 8.3.1  Axes. 

5.3.8.3.1.1  Design. 

a)  The  horizontal  (X-axis)  used  to  plot  time  or  the  postulated 
cause  and  the  vertical  (Y-axis)  is  used  to  plot  a  caused  effect. 

b)  When  graphed  data  represents  only  positive  numbers,  the 
graph  is  displayed  with  the  origin  at  the  lower  left. 

c)  When  the  data  include  negative  values  and  the  axes  extend  in 
both  directions  from  a  zero  point,  the  origin  is  displayed  in  the  center  of 
the  graph. 

d)  Unless  required  for  classification,  use  of  broken  axes  is 
restricted. 

e)  When  scaled  data  will  contain  extreme  values,  the  X-axis 
appears  at  both  the  top  and  bottom,  and  the  Y-axis  appears  at  both  the 
left  and  right  sides  of  the  graph,  and  grid  lines  are  provided. 

5. 3. 8. 3. 1.2  Markings  and  labels. 

a)  Values  on  an  axis  increase  as  they  move  away  from  the  origin. 

b)  Both  the  X-axis  and  Y-axis  are  clearly  labeled  with  title, 
symbol,  and  units. 
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c)  Logical,  mathematical  subdivisions  are  indicated  along  each 
axis.  Each  axis  interval  is  marked;  but  to  avoid  clutter,  usually  only 
every  other  interval  is  marked. 

5. 3. 8. 3. 2  Scales. 

a)  Each  scale  axis  is  labeled  clearly  with  its  description  and 
measurements  units. 

b)  Where  users  must  compare  graphic  data  across  a  series  of 
chails,  the  same  scale  for  each  chart  is  used.  When  users  must  compare 
aggregate  quantities  within  a  display,  or  within  a  series  of  displays, 
scaling  of  numeric  data  begins  with  zero. 

c)  Graphs  have  a  single  scale  for  each  axis.  Where  possible, 
common  scales  for  complex  graphics  are  provided. 

d)  Linear  scales  are  used  in  preference  to  logarithmic  or  other 
non  linear  scales. 

e)  Except  where  convention  or  customary  divisions  exist,  scales 
are  constructed  with  graduations  at  standard  intervals  of  1,2,  5,  or  10 
(or  their  multiples  by  10)  for  labeled  divisions.  Intervening 
graduations  are  consistent  with  the  labeled  scale  interval. 

5.3.8.3.3  Legends.  Where  possible,  each  cur.'e  within  a  single  graphic 
is  identified  directly  by  an  adjacent  label,  rather  than  by  a  separate 
legend.  If  a  legend  is  displayed,  the  codes  are  ordered  in  the  legend  to 
match  the  spatial  order  of  their  corresponding  curves  in  the  graph  itself. 

5.3. 8. 3. 4  Multiple  curves. 

a)  In  charts  displaying  multiple  curves,  curves  representing  data 
of  particular  significance  are  highlighted. 

b)  Line  coding  to  distinguish  curves  is  provided.  Consistent  line 
codes  are  used  to  represent  corresponding  data  in  a  series  of  charts. 

c)  Curves  representing  planned,  projected  or  extrapolated  data  is 
distinguishable  from  solid  curves  representing  actual  data. 

d)  Where  curves  must  be  compared  to  a  critical  value,  a 
reference  index  in  the  chart  is  provided. 

e)  Where  users  must  evaluate  the  difference  between  two  sets  of 
data,  a  difference  curve  is  displayed. 


f)  Where  curves  represent  cyclic  data,  extending  the  graph  to 
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repeat  uncompleted  portions  of  the  displayed  cycle  may  be  provided. 

5. 3. 8.3. 5  Surface  charts. 

a)  When  curves  represent  all  of  the  portions  of  a  whole,  surface 
charts  may  be  used  to  d'splay  aggregated  amounts. 

b)  The  areas  defined  below  the  curves  are  textured  or  shaded. 

c)  Data  categories  in  a  surface  chart  are  ordered  such  that  the 
least  variable  curves  are  displayed  at  the  bottom  and  the  most  variable  at 
the  top. 


d)  Where  space  permits,  areas  of  surface  charts  are  labeled 
directly  within  the  textured  or  shaded  bands. 

6)  Cumulative  curves  may  be  used  io  show  cumulative  totals. 
Cumulative  curves  are  not  used  to  extract  quantitative  or  rate  of  change 
data. 

5.3. 8.3.6  Grids. 

a)  When  necessary  grids,  are  provided  to  aid  in  data 
interpretation. 

b)  Grids  are  unobtrusive,  thinner  than  data  curves,  and  are 
invisible  behind  depicted  objects  and  areas  such  as  the  bars  on  a  bar 
chart. 

5.3. 8. 4  Bar  charts  and  histograms. 

a)  Bar  graphs  may  be  used  when  comparing  a  single  measure 
across  a  set  of  several  entities  or  for  a  variable  sampled  at  discrete 
intervals. 

b)  Histograms  may  be  used  when  there  are  a  great  many  entities 
or  intervals  to  be  plotted. 

5. 3. 8. 4.1  Format. 

a)  In  a  related  series  of  bar  nraphs,  a  consistent  orientation  of 
the  bars  is  adopted. 

b)  When  data  must  be  compared,  bars  are  adjacent  to  one  another. 
Adjacent  bars  are  spaced  such  that  a  direct  visual  comparison  can  be 
made  without  eye  movement. 

c)  A  reference  index  is  provided  when  displayed  values  must  be 
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compared  with  some  critical  value. 

d)  Stacked  bars  may  be  used.  Order  of  segment  stacking  is  by 
variablilty  of  each  segment,  with  the  least  variable  segment  being  the 
lowest  or  leftmost  segment,  and  the  most  variable  segment  being  the 
highest  or  rightmost  segment. 

e)  Use  of  iconic  representations  of  quantitative  information,  such 
as  when  a  silhouette  of  a  person  represents  1000  people,  is  avoided. 

5. 3. 8. 4. 2  Coding/labeling. 

a)  Charts  and  axes  are  clearly  labeled. 

b)  Important,  critical  or  frequently  referenced  information  is 
highlighted. 

c)  When  bars  are  displayed  in  pairs,  they  are  labeled  as  a  unit, 
with  a  legend  or  individual  distinguishing  labels  for  each  bar. 

5. 3. 8. 5  Flowcharts.  Flowcharts  may  be  used  for  schematic 
representation  of  sequences  or  processes,  as  an  aid  to  problem  solving. 

5. 3. 8. 5.1  Format. 

a)  Flowcharts  are  ordered  so  that  displayed  steps  follow  a  logical 

order. 

b)  When  there  is  no  inherent  logic  in  a  flowchart,  steps  are 
ordered  to  minimize  flowchart  size. 

c)  The  displayed  path  of  flowcharts  is  from  left  to  right,  from  top 
to  bottom,  or  clockwise. 

d)  Decision  points  require  a  singie,  simple  decision. 

e)  Decision  options  are  logically  ordered. 

f)  Decision  block  outcome  paths  are  consistent. 

5. 3. 8. 5. 2  Codino/labelino. 

a)  Symbol/shape  coding  and  line  coding  is  used  to  assist  in 
identifying  elements  and  flow  lines.  For  different  types  of  flowchart 
elements,  a  consistent  coding  scheme  is  followed. 

b)  Legends  are  displayed  on  each  figure  and  title  and  each  element 
is  clearly  labeled. 
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c)  Critical  steps/processes  in  a  flowchart  are  highlighted. 

5. 3. 8. 6  Maps  and  situation  displays.  Maps  and  situation  displays  are 
used  to  display  geographic  data,  i.e.,  direction  and  distance  relations 
among  physical  locations. 

5. 3. 8. 6.1  Format. 

a)  Orientation  of  maps  and  situation  displays  are  consistent  or 
under  user  control. 

b)  When  maps  present  large  geographic  areas,  a  consistent 
method  of  projecting  the  earth's  curvature  on  a  flat  display  surface  is 
specified  and  adopted. 

c)  Distance  judgments  from  map  displays  are  supported  through 
grid  overlays,  pointing  devices,  or  other  means. 

5. 3. 8. 6. 2  Coding/markinq/labelina. 

a)  When  it  can  be  done  without  cluttering,  significant  features  of 
a  map  are  labeled  direciiy  on  the  display. 

b)  When  different  areas  of  a  map  must  be  defined,  or  when  the 
geographic  distribution  of  a  variable  must  be  indicated,  color  or  other 
means  of  coding  is  provided. 

c)  Where  users  must  make  relative  judgments  for  different 
colored  areas  of  a  display,  tonal  codes  rather  than  spectral  codes  are 
used. 


ND 


d)  Texture,  pattern  or  tonal  variation  coding  are  selected  so  that 
the  darkest  and  lightest  shades  correspond  to  the  extreme  values  of  the 
coded  variable. 

e)  Highlighting  is  used  to  represent  data  of  particular 
significance. 

5.3.8. 6. 3  Data  presentation. 

a)  Where  possible,  demographic  or  other  data  on  map  displays 
are  presented  graphically  rather  than  by  using  text  descriptions. 


b)  When  it  is  necessary  to  show  the  geographic  location  of 
changing  data,  auxiliary  graphic  elements  are  combined  with  a  map 
background. 


200 


Checklist 


VES 


hD 


N/A 


c)  A  stable  reference  for  changing  data  is  provided. 

d)  When  map  or  situation  data  categories  are  variable,  the  user  is 
able  to  select  the  categories  needed  for  information  presentation. 

e)  Complex  data  analysis  is  supported  by  computer  processing. 
5.3. 8. 6. 4  Display  control. 

a)  When  a  map  exceeds  the  capacity  of  a  single  display  frame,  in 
terms  of  extent  and  detail  of  coverage,  panning  rather  than  paging  over 
the  area  is  provided. 

b)  When  a  user  pans  over  an  extended  display,  an  indication  of  the 
position  in  the  overall  display  is  provided. 

5. 3, 8. 7  Pictures  and  diagrams. 

a)  Pictorial  displays  are  used  to  show  representations  of  real  or 
imaginary'  objects  or  processes. 

b)  Diagrams  are  used  to  show  spatial  relations,  with  selective 
focus  on  the  data  specifically  required  by  a  user's  task  where  a  full 
pictorial  rendering  might  be  unnecessarily  complicated. 

5.3. 8. 7.1  Codino/labelinq. 

a)  Abstract  symbols  and  iconic  representations  may  be  used  to 
denote  objects  within  pictures  and  diagrams. 

b)  Symbols  are  standardized  and  a  legend  defining  symbols  is 
displayed  or  available  at  user  option. 

c)  Picture  or  diagram  data  of  particular  significance  is 
highlighted. 

5.3.8. 7.2  Display  control. 

a)  Where  a  user  must  examine  an  object  from  different 
perspectives,  the  user  is  able  to  rotate  the  displayed  image. 

b)  When  users  must  analyze  pictorial  images  in  detail,  computer 
aids  are  provided. 

c)  When  diagrammed  data  exceed  the  capacity  of  a  single  display 
frame  and  must  be  shown  in  separate  sections,  an  overview  of  the 
diagram  is  provided. 
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d)  A  logical  linking  of  a  diagrams  various  Sections,  and  an  easy 
means  of  movement  from  one  section  to  another,  is  provided. 

5. 3. 8. 8  Pie  chads. 

a)  A  pie  chart  is  used  only  to  show  the  relative  distribution  of 
data  amor:g  categories. 


b)  Pie  charts  are  not  used  when  the  viewer  is  to  extract 
quantitative  information. 

5  3.8.8.1  Eonnal- 

a)  Partitioning  is  limited  to  five  segments  or  less. 

b)  Segments  are  labeled  and  numbers  provided  to  their  segment 
labels  to  indicate  me  percentage  or  absolute  values  represented  in  the 
display. 


c)  When  a  segment  of  a  pie  chart  requires  emphasis,  it  is 
highlighted  by  special  hatching  or  shading  or  by  displacing  it  slightly 
from  the  remainder  of  the  pie. 

5. 3. 8. 8. 2  Codinq/labeling. 

a)  The  chart  and  each  segment  is  clearly  labeled.  If  a  segment  is 
too  small  to  contain  the  label,  the  label  is  placed  outside  the  segment  with 
a  line  from  it  to  the  segment. 

b)  When  required,  Quantitative  information  is  provided  on  the 

chart. 

5.3.8  9  Scatterplots. 

a)  Scatterplots  are  used  to  display  variable  correlations. 

b)  Data  of  particular  significance  is  highlighted. 

c)  When  scatterplots  are  grouped  in  a  single  display  to  show 
relations  among  several  variables,  means  to  highlight  selected  relations 
are  provided. 
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5.4.1  General.  In  addition  to  the  guidance  which  follows,  job 
performance  aids  display  design  also  follow  the  guidance  provided  in 
I  Section  5.3,  "Data  Display". 

a)  Standard  procedures  are  designed  for  similar,  logically  related 
transactions. 

b)  When  techniques  adopted  for  user  guidance  may  slow 
experienced  users,  alternative  modes  are  provided  which  allows 
bypassing  standard  guidance  procedures. 

c)  Explicit  actions  are  required  to  access  or  suppress  job 
performance  aids. 

d)  Users  are  able  to  switch  easily  between  information  handling 
transactions  and  presentation  of  guidance  material. 

5. 4. 1.2  Format. 

a)  Display  formats  are  consistent  and  readily  distinguishable 
from  displayed  data. 

b)  Critical  user  guidance  is  highlighted  using  the  same  methods 
used  to  highlight  critical  items  in  data  display. 

c)  When  hierarchic  menus  are  used,  they  are  organized  and 
labeled  to  guide  users  within  the  hierarchic  structure. 


d)  A  standard  symbol  is  used  for  prompting  entry. 


5.4. 1.3 


a)  Wording  is  familiar  to  the  user,  oriented  to  the  ta-^k,  provide 
guidance  directly. 

b)  Active  rather  than  passive  voice  is  used  in  guidance  messages. 


c)  Messages  are  worded  concisely,  using  consistent  grammatical 
structures,  phrasing  and  punctuation. 

d)  When  traiisacticns  occur  by  a  sequence  of  steps,  the  same 
sequence  is  used  in  the  wording  of  user  guidance. 
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e)  Coding  abbreviations  and  wording  conventions  follow  the 
display  design  guidance  presented  in  section  5.3.6,  "Text". 


5.4. 1.4 


a)  Computer  generated  speech  output  may  be  used  for  guidance 
messages  in  environments  with  low  ambient  noise,  when  a  users 
attention  may  not  be  directed  toward  a  visual  display,  or  when  providing 
a  visual  display  is  impractical. 

b,  Csmputor  generated  speech  messages  are  limited  in  number, 
distinctive  trom  routine  messages,  short  and  simple. 


I 
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5  4  1.5  Pertjrmance  monitoring. 

a,  n  aprdications  where  skilled  user  performance  is  critical  to 
system  r.per.itton,  automatic  computer  recording  and  assessment  of  user 
pcrforrnancu  is  provided,  in  terms  of:  data  accessed,  user  errors,  help 
requests,  'jser  transactions  and  programs  used. 

hj  Usr.es  are  informed  of  any  records  kept  of  individual 
performance 


5,4.1 ,6  On-line  training.  Where  possible,  on  line  training  capability 
s  provided  with  difterent  levels  of  training  for  on-line  job  supptort  and 
adapt  automatically  to  user  abilities. 
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5.4.2  Diila_dLSi^l£iy. 

a)  Users  are  able  to  request  help  and  obtain  detailed  on  line 
guidance  by  using  standard  actions  that  are  always  available. 

b)  Synonyms  for  standard  terminology  are  reccgnized  by  help 
routines. 

c)  Multilevel  help  is  under  user  control.  Users  are  able  to 
browse  through  on-line  help  displays. 

d)  Help  messages  are  tailored  to  task  and  transaction. 

e)  Requests  for  help  in  ambiguous  contexts  initiates  a  dialog  in 
which  the  user  can  specify  what  data,  message  or  command  requires 
explanation. 

h  After  requesting  help,  the  user  is  provided  with  easy  means  io 
return  to  the  main  dialog. 

5. 4. 2. 2  Information  or 


a)  Specific  user  guidance  information  is  available  for  display  at 
any  point  in  a  transaction  sequence. 

b)  Only  guidance  information  relative  to  transactions  of  interest 
is  displayed. 

c)  During  transaction  sequences,  guidance  is  provided  telling  the 
user  how  to  continue. 

5.4  2.2. 1  Status  information. 

a)  indication  of  system  status  is  continuously  presented  to  users 

b)  Active  operational  modes  are  clearly  indicated  to  the  user. 

c)  Users  are  able  to  obtain  status  information  concerning  current 
alaTn  sett'ngs,  in  terms  of  dimensions  (variables)  covered  and  values 
('categories)  established  as  critical. 


i  d)  When  interaction  is  required  with  other  users  or  systems, 

i  io'Grnial'on  concernmn  the  others  status  is  provided. 
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ND 
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e)  Level  of  systein  performance  is  indicated. 

5. 4. 2. 2.2  Control  information. 

a)  A  general  list  of  help  control  options  are  available  and  are 
displayed  in  logical  groups. 

b)  Where  command  entry  is  used,  an  on-line  command  index  is 
available. 

c)  Control  options  that  are  specific  to  individual  help  messages 
are  indicated  on  the  display. 

d)  Advisory  messages  or  prompts  are  provided  to  guide  users  in 
accessing  help  messages. 

e)  Reference  material  describing  system  capabilities  and 
procedures  is  available  for  on-line  display. 

f)  Users  are  not  required  to  memorize  lengthy  sequences  or  to 
refer  to  secondary  written  procedural  references  to  access  help 
messages. 

g)  Where  the  user  can  choose  help  data  to  display,  an  on-line 
index  is  provided. 

h)  When  a  user  help  request  depends  upon  context  established  by 
previous  entries,  an  indication  of  that  context  is  provided  to  the  user. 

i)  Users  are  able  to  request  a  displayed  record  of  past 
transactions. 


vs  ro  N/A 


5.4.3. 1  Routine  feedback.  Computer  response  fo  user  entries  is  rapid, 
with  consistent  timing  as  appropriate  for  different  types  of  transactions. 

5. ■"3.1.1  information  presented. 


a)  Routine  feedback  is  provided  as  transactions  are  processed  and 
completed. 

‘  b)  Feedback  is  provided  for  all  user  interrupts,  indicating  when 

the  system  has  returned  to  a  previous  or  normal  status. 

c)  Indication  of  transaction  status  is  provided  whenever  complete 
processing  will  be  delayed. 

d)  When  requests  for  printed  output  are  handled  by  a  remote 
printer,  feedback  for  print  requests  is  provided. 

5. 4. 3. 1.2  Format. 

a)  Displays  are  uniquely  identified  at  the  top  of  each  display 

frame. 

b)  Selected  or  active  options  are  displayed  automatically  or  at 
user  request. 

c)  Items  selected  to  perform  operations  are  highlighted. 

5.4.3.2  Error  feedback. 

a)  Error  feedback  is  provided  if  an  error  or  other  unexpected 
event  prevents  processing  and  is  displayed  within  2  seconds  of  the  entry 
in  which  the  error  is  detected. 

b)  An  error  message  is  not  generated  as  wrong  data  are  keyed,  but 
only  after  an  explicit  ENTER  action  has  been  taken. 

c)  To  supplement  on-line  guidance,  system  documentation 
contains  a  listing  and  explanation  of  all  error  messages. 


d)  Conditions  requiring  special  user  attention  use  distinctively 
coded  alarms. 


ND  N/A 


5.4.3. 2.1  Information  presented. 

a)  Error  information  reflects  the  user's  point  of  view  in  terms  of 
what  is  wrong  and  what  can  be  done. 

b)  When  multiple  errors  are  detected  in  merged  commands,  the 
user  is  notified  of  each  occurrence. 

c)  When  a  user  repeats  an  entry  error,  feedback  is 
distinguishable  from  the  first  occurrence  to  avoid  uncertainty  whether 
the  computer  has  processed  the  revised  entry. 

d)  Erroneous  entries  and  error  messages  are  displayed  until 
corrections  are  made,  and  are  not  displayed  after  the  error  has  been 
corrected  or  is  no  longer  applicable. 

e)  When  a  process  is  completed  or  aborted  by  the  system,  the 
user  is  informed  about  the  outcome  of  the  process  and  any  requirements 
for  subsequent  actions. 

f)  The  user  does  not  have  to  search  through  reference  material  to 
interpret  system  messages.  However,  error  messages  may  refer  the 
user  to  specific  on-line  documentation. 

g)  When  possible,  users  are  able  to  request  more  detailed  error 
messages. 

5.4.3.2.2  Wording  and  Style. 

a)  Error  messages  are  informative,  nonthreatening,  brief,  as 
specific  as  possible,  and  employ  neutral  wording. 

b)  W'ording  for  error  messages  is  appropriate  to  a  users  task. 

'  5. 4. 3. 2.3  Cursor  positioning.  7  he  cursor  is  positioned  at  the  point 
where  an  error  was  detected. 

5.4. 3. 2.4  User  response. 


a)  U,sers  are  required  to  reenter  only  the  portion  of  a 
data/cornmand  entry  which  is  not  correct  and  do  not  have  to  rekey  an 
entire  command  string  or  data. 

b)  Users  are  required  to  confirm  destructive  entries  before  they 
will  be  executed  by  the  the  computer. 
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5.5  Expert  systems. 

5.5.1  General. 

a)  Expert  system  development  is  based  on;  user  requirements; 
preferred  dialog  types;  knowledge  engineer  requirements;  operational 
requirements;  and  mental  models  employed  by  the  human  expert  and  the 
user. 

b)  A  detailed  description  of  the  functional  transactions  between 
the  system  and  user  is  developed  and  validated  prior  to  specifying  the 
internal  structures  of  the  system. 

5.5. 1.1  Representing  causality. 

a)  To  the  extent  possible,  the  expert  system  is  capable  of 
identifying  and  representing  causality  between  facts  contained  in  its 
knowledge  base. 

b)  At  the  request  of  the  user,  the  expert  system  is  capable  of 
representing  forward  causality,  in  the  form  of  predictions,  and 
backward  causality,  in  the  form  of  speculative  reconstruction  of  events. 

5.5. 1.2  Specify  domains. 

a)  In  selecting  knowledge  (facts)  to  be  contained  in  the  knowledge 
base,  both  a  domain  model  and  a  set  of  domain  principles  are  established. 

b)  The  domain  model  contains  descriptive  causal  relationships 
and  classification  hierarchies,  including:  failure  modes,  conditions  and 
effects;  symptoms;  measures/estimates  of  criticality/priority;  and, 
alternative  responses. 

c)  The  set  of  domain  principles  contain  prescriptive  methods  and 
heuristics,  including;  hypotheses  to  be  developed;  data  to  be  acquired; 
tests  to  be  conducted;  and,  decisions  to  be  made. 


VES  N/A 


5.5.2  Dialog. 

a)  The  system  supports  a  flexible  dialog  that  permits  either  the 
user  or  the  expert  system  to  initiate  an  action  or  request  for 
information,  without  cancelling  an  ongoing  transaction. 

b)  The  user-expert  system  dialog  is  flexible  in  terms  of  the  type 
and  sequencing  of  user  input  it  will  accept. 

c)  When  inexperienced  users  are  required  to  interact  with  the 
expert  system,  menu,  form  filling,  query  or  question/answer  dialog 
modes  are  preferred  over  command  language  dialog  modes. 

d)  The  system  is  designed  to  permit  rapid  retrieval  of  previous 
exchanges  between  the  user  and  the  expert  system  for  the  current 
transaction.  The  preferred  method  for  such  retrieval  is  scrolling. 

e)  User-expert  system  information  exchange  is  based  on:  the 
range  of  data  types  which  will  be  input  by  the  user;  the  extent  and 
frequency  of  each  data  type  entry;  how  user-generated  data  be  acquired; 
the  range  of  data  types  which  will  be  output  by  the  expert  system;  the 
extent  and  frequency  of  each  data  type  output;  and  pacing  of  user  queries. 

f)  For  the  mode  of  expert  system  dialog  selected,  the  appropriate 
guidelines  of  section  5.2,  "Dialog/Interaction  Control",  also  apply  to 
expert  systems  dialog  design. 
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5.5.3  Problem  Statement/input. 

5. 5.3.1  Problem  definition  and  consultation  planning. 

a)  The  expert  system  provides  the  capability  for  the  user  to  plan 
a  strategy  for  addressing  a  problem.  This  plan  may  include  data  to  be 
acgutfeu,  iiy^ciiiesc^b  to  be  iCStsd,  c«ttcric  for  acccpting/rcjeotniQ 
hypotheses,  etc. 

b)  The  capability  provided  by  the  expert  system  includes: 
planning  aids;  an  evaluation  function  which  assesses  the  adequacy  of  the 
user's  plan  and  recommends  revisions  where  necessary;  the  ability  to 
form,  state  and  test  hypotheses  in  a  manner  consistent  with  the  user's 
plan:  and,  the  capacity  to  store  and  recall  plans. 

5. 5.3.2  Consultation. 

a)  The  expert  system  is  capable  of  supporting  a  complete  range  of 
problem  solving  strategies,  including:  reliability;  conditional 
probability;  syndrome/symptom  analysis;  signal  tracing;  half-split; 

and,  bracketing. 

b)  The  expert  system  is  capable  of  accepting  direction  from  the 
user  in  terms  of  which  strategy  to  employ. 

c)  The  control  strategy  supports  both  forward  (data-driven)  and 
backward  (goal-driven)  chaining  to  allow  ‘he  user  or  expert  system  to 
provide  data  or  propose  a  new  or  revised  goal,  as  appropriate,  for  the 
transaction  underway. 

d)  The  system  is  capable  of  supporting  speculative  analysis  by 
providing  a  "reconnoiter  mode"  that  allows  the  user  to  investigate  the 
effects  of  an  action  without  actually  implementing  the  action. 

e)  Entering  a  reconnoiter  mode  requires  an  explicit  command  by 
the  user  and  results  in  a  clearly  distinguishable  change  in  system  output 
to  ensure  that  the  user  is  apprised  of  the  change  in  operating  mode. 

f)  The  expert  system  is  capable  of  providing  interactive 
explanations  using  the  facts  and  rules  contained  in  its  knowledge  base. 

g)  The  knowledge  required  to  perform  all  functions  allocated  to 
the  expert  system  is  directly  accessible  by  the  expert  system. 

h)  Requirements  for  the  expert  system  to  query  the  user  to 
obtain  information  for  routine  functions  are  minimized. 

i)  The  capability  for  the  user  to  supercede  the  current  request 
for  information  from  the  expert  system  in  order  to  input  information 
related  to  a  different  transaction  is  provided. 
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j)  The  user  does  not  have  to  complete  all  elements  of  an  expert 
system  requested  form  in  order  to  complete  a  phase  of  a  transaction. 
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I  5.5.4  Display. 


1  S  5  4  1  Dynamic  infcmction. 

. 

a)  With  the  exception  of  mission-critical  information,  display  of 
dynamic  information  "freezes"  during  extended  explanation  sessions  to 
ensure  that  a  significant  change  in  status  does  not  escape  notice  by  the 

user. 

b)  At  the  completion  of  the  explanation  session,  the  system 
updates  and  highlights  any  changes  in  displayed  values,  and  request 
acknowledgment  by  the  user. 


c)  If  mission-critical  information  becomes  available  during  an 
extended  explanation  session,  the  system  alerts  the  user,  via  prompts  or 
other  alarm  mechanisms,  and  immediately  displays  the  information  to 
the  user. 

5. 5.4. 2  Graphics  interface. 

a)  The  expert  system  has  the  capability  to  graphically  represent 
its  rules  network.  This  capability  is  available  to  the  user  as  an  adjunct 
to  the  explanation  subsystem. 

b)  Graphics,  such  as  a  system  schematic,  is  used  to  depict 
relationships  between  system  configuration  and  measurable  parameters. 


c)  To  the  extent  possible,  graphics  portray 
system/component/process  status  through  the  use  of  color,  shading,  or 
similar  coding  techniques. 

d)  Coding  techniques  are  consistently  applied  across  tfie  expert 

system. 

e)  The  guideline  of  Sections  5.1 .8  "Iconic  Interaction",  5.2.6 
"Graphics  Entry",  and  5.3.8  "Data  Display  (Graphics)"  apply  to  expert 
systems  graphic  interfaces. 


5  5.4.3  Off-line  printing. 

a)  The  expert  system  has  access  to  an  off-line  printer  to  allow 
the  user  to  request  hardcopy  of  screen  displays,  summaries  of  extended 
consultations,  lists  of  rules/facts  invoked  during  a  consultation. 
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b)  The  printer  may  be  used  as  an  alternative  display  device  to 
free  up  the  primary  workstation. 


5.5.5.1  Weiohtir 


a)  Certainty  factors  reflect  a  weighted  combination  of 
probabilistic  and  cost-benefit  judgments. 

b)  Cost-benefit  judgments  are  based  on  a  formal  weighting 
scheme  that  reflects  the  relative  priorities  for  different  classes  of 
failures. 

c)  The  rationale  underlying  the  weighting  is  explicitly  encoded. 


a)  The  rule  set  for  an  expert  system  is  capable  of  representing 
certainty  factors  to  the  user. 

b)  Certainty  factors  may  be  contained  in  the  data,  in  one  or  more 
rules,  or  both. 

c)  Certainty  factors  are  represented  as  a  decimal  number  from 
-1  to  -t-1 ,  with  -1  indicating  absolute  certainty  that  a  fact  is  not  true, 
and  -t-1  indicating  absolute  certainty  that  a  fact  is  true. 

d)  Certainty  factors  displayed  to  the  user  reflects  the  cumulative 
certainty  for  all  elements  of  the  conclusion  being  drawn. 

e)  In  addition  to  numerical  values  of  certainty,  the  system  is 
capable  of  providing  some  indication  of  rationale  underlying  the 
uncertainty,  such  as  conditions  when  the  rule  was  invalid. 


ND  N/A 


a)  The  expert  system  is  capable  of  explaining  its  behavior, 
problem  solutions,  and  knowledge. 

b)  At  any  point  during  a  consultation,  the  expert  system  is 
capable  of  displaying  the  rule  currently  being  invoked. 

c)  The  expert  system  automatically  records  all  rules  invoked 
during  a  consultation. 

d)  Poliowing  a  consultation,  the  explanation  facility  is  capable  of 
recalling  each  invoked  rule  and  associating  it  with  a  specific  event  to 
explain  the  rationale  for  the  event. 

e)  The  explanation  facility  is  able  to  search  the  knowledge  base  to 
locate  rules  or  items  of  knowledge  in  response  to  specific  inquiries  from 
the  user,  to  alert  the  user  when  a  problem  is  beyond  its  current 
capabilities,  and  instruct  the  user  as  to  what  additional  knowledge  or 
rules  would  be  required  to  complete  the  transaction. 

0  The  expert  system  is  able  to  respond  to  user  requests  to  clarify 
or  restate  questions  and  assertions. 

g)  The  system  is  capable  of  displaying  both  rule-based  and 
descriptive  explanations,  as  requested  by  the  user. 

h)  At  any  point  during  a  transaction,  the  expert  system  is  able  to 
explain  which  problem  solving  strategy  is  being  employed,  why  a 
particular  strategy  was  selected,  and  the  current  status  of  the 
application. 

5.5.6. 1  Lanauaae/stvie. 


a)  The  presentation  of  information  to  explain  or  justify  the 
behavior  or  knowledge  of  the  expert  system  is  consistent  in  content  and 
format  with  the  cognitive  strategies  and  mental  models  employed  by  the 
user,  particularly  when  the  user  and  the  expert  system  are 
independently  working  the  same  problem. 

b)  At  a  minimum,  the  explanation  facility  employs  the  same 
nomenclature,  abbreviations  and  acronyms  for  system  elements  as  those 
employed  by  the  user. 
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c)  The  system  is  capable  of  emulating  a  degree  of 
"self-awareness"  by  portraying,  via  the  explanation  facility,  the 
knowledge  it  contains  concerning  the  application,  relevance  and  validity 
of  rules  and  knowledge  (facts)  contained  in  its  knowledge  base. 

d)  Explanation  facility  knowledge  includes  an  understanding  of  the 
strategies  and  processes  by  which  rules  and  facts  are  applied. 

e)  The  guidelines  of  Section  ti.3.6  "Text  [display]"  are  applied  to 
explanation  facilities  design. 

5.5.6.2  Strategy  explantion.  At  any  point  during  a  transaction,  the 
expert  system  is  able  to  explain  which  problem  solving  strategy  is  being 
employed,  why  a  particular  strategy  was  selected,  and  the  current  status 
of  the  application. 


sMSNKliwIilM 


a)  Rules  are  represented  explicitly  in  the  knowledge  base  and 
encoded  in  such  a  manner  that  it  is  accessible  to  the  explanation  facility 
and  can  be  translated  for  human  understanding. 

b)  The  content  and  detail  of  a  rule's  explanation/justification  are 
consistent  with  the  classification  of  the  rule. 


c)  For  most  systems,  rules  may  be  assigned  to  one  of  the 
following  classes:  identification  rules;  causal  rules;  world  fact  rules; 
domain  fact  rules. 

d)  Rule  exceptions  are  explicitly  contained  in  the  knowledge  base 
and  are  available  to  th  j  user  as  part  of  the  explanation  facility. 

e)  The  explanation  facility  has  access  to  the  rationale  by  which 
the  hypotheses  in  a  rule's  premise  were  ordered. 

0  The  rationale  for  ordering  hypotheses  is  explicitly  represented 
for  the  following  classes  of  hypotheses;  hypotheses  related  to  personnel 
health  and  safety;  hypotheses  related  to  mission  success, 
mission-critical  equipment  or  mission-critical  data;  hypotheses 
related  to  nonmission-critical  equipment  or  data;  hypotheses  related  to 
mission  efficiency  and  economics. 


VES  ND  N/A 


a)  The  level  of  detail  of  information  presented  as  part  of  an 
explanation  or  justification  is  under  the  control  of  the  user. 

b)  The  user  is  able  to  specify  three  levels  of  detail:  rules  only, 
brief  explanations  and  detailed  explanations. 

c)  Control  of  the  explanation  facility  is  designed  such  that  the 
user  may  specify  the  level  of  detail  as  a  default  option  at  the  beginning  of 
a  transaction. 

d)  For  any  individual  explanation,  the  user  is  able  to  request 
greater  or  lesser  detail. 

e)  Systems  employing  means-ends  analysis  as  an  element  of  the 
control  strategy  provides; 

1 )  a  description  of  the  current  state 

2)  a  description  of  the  goal  stale 

3)  a  description  of  the  difference  between  the  current 
state  and  the  goal  state 

4)  descriptions  of  all  candidate  operators  (rules), 
including  the  type  and  amount  of  difference  they 
eliminate 

5)  a  description  of  the  strategies  for  transforming  the 
current  state  or  revising  the  goal  state. 

5. 5.6, 5  Representing  reasoning.  When  representing  its  reasoning 
process  to  the  user,  the  expert  system  is  capable  of  describing  how  well 
the  observed  data  support  each  hypothesis  under  consideration  and  how 
well  each  hypothesis  under  consideration  account  for  the  observed  data. 


Checklisi 


YES 


ND 


N/A 


5.6  Data  communication. 

5.6.1  General. 

5. 6. 1.1  User  control/procedures. 

a)  Data  transmission  functions  are  integrated  with  other 
information  handling  functions  within  a  system. 

b)  Procedures  for  preparing,  sending  and  receiving  messages  are 
consistent  between  transactions  and  other  information  handling  tasks. 

c)  Data  transmission  procedures  are  designed  to  minimize 
memory  load  on  the  user  and  to  minimize  required  user  actions. 

d)  Both  sending  and  receiving  messages  is  accomplished  by 
explicit  user  action. 

e)  Users  are  provided  flexible  control  of  data  transmission,  in 
terms  of  what,  when  and  where  data  are  transmitted. 

f)  Users  are  able  to  interrupt  message  preparation,  review,  or 
disposition,  and  resumption  is  from  the  point  of  interruption. 

5. 6. 1.2  Wording  and  message  content. 

a)  Functional  task  oriented  wording  is  used  for  terms  in  data 
transmission. 

b)  Transmitted  data  is  annotated  with  any  alarm/alert  conditions, 
priority  indicators,  or  other  significant  information. 


Checklist 


YES 


N/A 


5. 6. 2.1  Procedures 

a)  Procedures  for  composing  messages  follow  the  general  data 
entry  and  editing  procedures  presented  in  Section  5.3  "Data  Entry"  of 
this  handbook. 

b)  Users  do  not  have  to  learn  procedures  for  entering  message 
daia  that  are  different  from  general  data  entry. 

5. 6. 2. 2  User  control. 

a)  Users  are  provided  means  to  specify  data  to  be  transmitted  and 
are  able  to  incorporate  existing  file  data  in  messages. 

b)  Users  are  able  to  prenare  arid  transmit  messages  of  any  length. 

c)  Users  are  able  to  save  draft  messages  during  preparation,  or 
upon  completion. 

d)  When  messages  must  be  transmitted  following  data  change,  the 
user  confirms  that  the  data  am  ready  to  *^6  transmitted. 

5. 6. 2. 3  Format. 

a)  Unless  a  need  exists  for  a  specific  message  format,  users  are 
able  to  compose  and  transmit  messages  with  a  format  of  their  own  design, 
and  to  compose  and  transmit  messages  as  unformatted  text. 

b)  When  messages  must  conform  to  defined  formats  and 
standards,  preformatted  forms  are  available  to  users. 

c)  Where  possible,  the  system  provides  automatic  message/text 
fr'uriatting  for  optional  use. 

d)  In  forms  preparation  for  transmission,  users  are  able  to 
enter,  review,  and  edit  data  on  any  display  organized  with  labeled  fields. 

e)  Users  are  able  to  enter,  review,  and  change  tabular  or  graphic 
data  in  customary  formats;  e.g.,  row/columns. 


NO  '  N/A 


5.6.3.1 


5.6.3.1.1  User  conlrgl- 

a)  Users  are  able  to  specify  destinations  where  data  will  be 
transmitted  by  system  users,  other  work  stations,  terminals,  or  users 
of  other  systems. 

b)  Users  are  able  to  edit  the  address  fields  in  the  header  of  a 
message  being  prepared  for  transmission. 

5. 6. 3. 1.2  Format. 

a)  A  basic  set  of  header  fields  (DATE,  TO,  FROM,  COPIES,  TIME, 
"etc.“  that  can  be  interpreted  by  all  systems  to  which  messages  will  be 
sent)  is  provided. 

b)  Prompting  is  used  to  guide  the  user  in  specifying  the  address 
for  a  message. 

c)  The  address  of  a  recipient  occurs  only  once  in  a  message. 

5.6.3. 1.3  Direclories/distribution  lists. 

a)  Address  directories  are  provided  in  which  users  are  able  to 
search  address  directories  by  specifying  a  complete  or  partial  name,  or 
other  address  information  and  are  able  to  select  addresses  without 
reentering  the  information. 

b:  Use's  are  able  to  define  names  for  commonly  used  addresses, 
to  save  those  :ri  a  file,  and  to  address  messages  by  name. 

c;  i  l',.  's  are  providf?d  with  information  about  distribution  lists 
on  which  (  o  e.  ir-  :i  jded.  and  lists  they  are  authorized  to  use. 

c>  i  O  '  re  .ire-  able  to  create  and  modify  their  own  lists,  and  within 
a  diitnbu;  on  n  ,t.  users  are  able  to  include  other  distribution  lists  as 

well  as  iridivid'jrii  add'essos- 


rt;  Wtiere  coorctinated  review  of  messages  by  several  recipients  is 
required,  tti<;  oeiider  is  able  to  specify  a  serial  distribution  so  that  a 
message  will  be  passed  from  one  recipient  to  the  next. 


Checklist 


YES 


ND 


N/A 


5. 6.3. 1.4  Validation  and  error  correction. 

a)  Computer  checks  for  address  accuracy  are  provided. 

b)  Users  are  required  to  correct  mistakes  before  initiating 
message  transmission. 

c)  Users  are  able  to  print  copies  of  transmitted  messages. 

5.6.3.2  Initiating  transmission. 

5.6.3.2.1  System  control. 

a)  Wiien  standard  messages  must  be  transmitted  means  are 
provided  to  initiate  transmission  automatically. 

b)  Automatic  queuing  of  outgoing  message  is  provided  to  reduce 
user  involvement  in  routine  transmission. 

5. 6. 3. 2. 2  User  control. 

a)  Users  are  able  to  initiate  data  transmission  directly,  by 
entering  an  explicit  SEND  command. 

b)  Users  are  able  to  choose  whether  to  transmit  a  displayed 
version  of  a  message,  or  to  transmit  directly  from  stored  files. 

c)  Users  are  able  to  assign  priority  to  messages,  and  to  defer  the 
transmission  of  messages  to  a  specific  date,  time,  or  by  later  action. 

d)  Message  transmission  is  provided  with  annotations  such  as 
"RECEIPT  REPLY  REQUESTED",  under  sender's  control. 

e)  Senders  are  abie  to  cancel  or  abort  a  transmission  that  has  not 
been  completed  or  initiated. 

5.6. 3.2.3  Data  display. 

a)  Status  information  concerning  the  identity  of  other  system 
users  currently  on-line  is  available. 

b)  When  a  message  is  sent,  the  computer  appends  the  sender's 
address,  and  the  date  and  time  of  message  creation  and  transmission. 


Checklist 


5. 6. 3.3  Controlling  transmission. 


YES 


5. 6. 3. 3.1  System  control. 

a)  Transmitted  data  are  protected  automatically  with  parity 
checks  to  detect  and  correct  any  errors  that  may  occur. 

b)  Automatic  feedback  is  provided  for  data  transmission, 
confirming  that  messages  have  been  sent,  or  indicating  transmission 
failures. 

c)  Only  one  copy  of  any  message  is  transmitted  to  an  individual 
addressee. 

5. 6. 3. 3. 2  User  control. 


a)  Users  are  able  to  specify  what  feedback  will  be  provided  for 
message  transmission,  and  to  request  specific  feedback  for  particular 
messages. 

b)  Users  are  able  to  recall  or  abort  transmissions  after 
initiation,  if  messages  have  not  been  received. 

c)  When  required,  automatic  record  keeping  is  provided. 

5. 6. 3.4  Transmission  failure. 

a)  In  the  event  of  transmission  failure,  automatic  queuing  is 
provided  to  preserve  outgoing  messages. 

b)  If  message  transmission  fails,  automatic  storage  of 
undelivered  messages  is  provided,  and  the  sender  is  notified.  Notification 
includes  an  explanation  of  the  failure. 


5. 6. 4.1  System  control. 

a)  Incoming  messages  are  automatically  queued  by  time  of 
receipt,  message  priority,  or  user  specification,  pending  subsequent 
review  and  disposition  by  the  user. 

b)  Logs  of  messages  received  and  sent  are  automatically 
maintained  by  the  system. 

5. 6. 4. 2  User  control. 

a)  Users  are  able  to  specify  data  that  may  be  received,  by 
specifying  receipt  priority  or  other  means,  and  are  able  to  choose  what 
device  will  receive  messages. 

b)  Users  are  able  to  specify  "filters"  based  on  message  source, 
priority,  type,  or  content,  that  will  control  notification  for  incoming 
messages. 

c)  Users  are  able  to  assign  their  own  names  and  other  descriptors 
to  received  messages. 


d)  Users  are  able  to  discard  unwanted  messages  without  filing. 


VS  ND  N/A 


5.6.4. 


a)  Means  are  provided  for  users  to  specify  message  summary 
listing  orders. 

b)  Unless  required  for  security  or  other  procedure,  means  for 
review  of  messages  are  provided  without  requiring  user  disposition  . 

c)  Users  are  able  to  review  summary  information  about  the  type, 
source,  and  priority  of  queued  incoming  messages. 

d)  Display  designs  for  received  messages  are  consistent  with 
general  data  display  guidelines  presented  in  Section  5.3.6  "Data  Display 
-  Text". 

e)  Users  are  able  to  annotate  reviewed  messages.  Annotations  are 
displayed  and  are  distinct  from  the  message  itself. 

f)  An  indication  of  message  size  is  included  in  message  summaries 
and  at  the  beginning  of  each  incoming  message. 


Checklist 


YES 


N/A 


5.6.4.4  Format. 

a)  If  data  transmission  arrives  in  an  incorripdible  format, 
recipients  are  advised. 

b)  Incompatible  formats  do  not  destroy  the  incoming  message  or 
any  ongoing  transactions  of  the  receiver. 

5.6.4.5  Data  display. 


a)  Users  are  notified  at  log-on  of  any  data  transmissions  received 
since  last  use  of  the  system. 

b)  Notification  of  arriving  messages  do  not  interfere  with  a  users 
ongoing  tasks. 

c)  Priority  of  received  messages  is  indicated  in  applications 
where  incoming  messages  will  have  different  degrees  of  urgency,  i.e., 
different  implications  for  action. 

5.6.4.6  Reply.  When  replying  to  a  message,  the  appropriate 
address(es)  is  provided  automatically. 


VES  N/A 


5.7.1  General. 

a)  Clear  and  consistent  procedures  are  provided  for  different 
types  of  transactions,  particularly  those  involving  data  entry,  change, 
deletion,  and  error  correction. 

b)  The  system  deals  appropriately  with  all  possible  user  errors 
and  random  inputs,  without  introducing  unwanted  data  change. 

5.7.1. 1  System  control. 


a)  Automatic  measures  to  minimize  data  loss  from  computer 
failure  is  provided. 

b)  Whenever  possible,  automated  measures  for  data  security  is 
provided,  relying  on  computer  capabilities  rather  than  on  humans. 

c)  When  a  proposed  user  action  will  interrupt  a  current 
transaction  sequence,  automatic  means  to  prevent  data  loss  is  provided. 

d)  Where  potential  data  loss  cannot  be  prevented,  the  user  is 
warned,  and  the  action  is  not  implemented  without  user  confirmation. 

e)  When  function  keys  or  other  devices  are  not  needed  for  a 
transaction  type  and  when  they  may  have  destructive  effects,  they  are 
disabled  under  software  control  to  avoid  activation. 

f)  Automatic  defaults,  if  provided  for  control  entries,  protects 
against  data  loss,  and  does  not  contribute  to  the  risk  of  data  loss. 

5.7. 1.2  User  actions. 

a)  Data  are  protected  from  inadvertent  loss  caused  by  the  actions 
of  other  users. 

b)  Users  are  able  to  designate  their  own  files  and  data  as  protected 
from  the  actions  or  access  of  others. 

c)  Frequent  or  urgent  actions  are  easy  to  perform,  potentially 
destructive  actions  are  sufficiently  difficult  to  require  additional  user 
attention. 

d)  Unless  real-time  computer  monitoring  is  performed,  data  is 
changed  only  as  a  result  of  explicit  user  actions. 


Checklist 


YES 


N/A 


e)  Explicit  action  to  select  destructive  rnodes  is  required. 


f)  Users  are  required  to  take  an  explicit  extra  action  to  CONFIRM 
a  potentially  destructive  or  critical  control  entry  before  it  is  accepted 

by  the  computer  for  execution. 

g)  A  CONFIRM  action  is  distinctively  labeled. 

h)  Users  are  required  to  wait  for  computer  prompting  to 
CONFIRM  so  that  the  confirmation  will  constitute  a  second,  separate 
action. 


i)  Users  are  able  to  UNDO  an  immediately  preceding  control 
action  that  may  have  caused  an  unintended  data  loss. 

j)  Users  are  not  able  to  change  protected  or  controlled  data. 

5. 7.1. 3  Simulation  and  training. 

a)  When  simulated  data  are  used  in  conjunction  with  system 
functions,  actual,  unsimulated  data  is  protected. 

b)  Operational  system  use  is  clearly  indicated  and  distinguishable 
from  simulated  operations. 

a)  Computer  logic  that  will  generate  messages  or  alarm  signals 
is  provided  to  warn  users  of  potential  threats  to  data  security. 

b)  A  continuous  indication  of  the  current  operational  mode  is 
displayed,  particularly  when  transactions  might  result  in  data  loss. 

c)  For  conditions  which  may  require  special  user  attention  to 
protect  against  data  loss,  an  explicit  alarm  or  warning  message  is 
provided  to  prompt  appropriate  user  action. 


Checklist 


YES 


N/A 


5. 7.2.1  Unauthorized  access.  A  limit  on  the  number  and  rate  of 
unsuccessful  LOG-ON  attempts  is  imposed  to  provide  a  margin  for  user 
error,  while  protecting  the  system  from  persistent  attempts  at 
illegitimate  access. 

5.7.2.2  Identification  and  passwords. 


a)  LOG-ON  processes  are  designed  to  provide  prompts  for  all  user 
entries,  including  passwords  and  other  data  required  to  confirm  user 
identity  and  to  authorize  data  access  privileges. 

b)  When  system  security  requires  more  stringent  user 
identification  than  is  provided  by  password  entry,  auxiliary  tests  may  be 
used  that  authenticate  user  identity,  but  does  not  impose  impractical 
demands  on  users  memory. 

c)  Users  are  able  to  choose  or  change  their  own  passwords. 

d)  Where  data  protection  is  critical,  user  selected  passwords  are 
tested  against  a  list  of  common  passwords  or  commonly  known  user  data. 

e)  When  a  password  must  be  entered  by  a  user,  password  entry  is 
private;  password  entries  are  not  displayed,  but  display  echoes  (such  as 
. )  for  each  keystroke  is  provided. 

f)  Unless  a  specified  period  of  inactivity  has  expired  or  under 
special  security  procedures,  whatever  data  access/change  privileges  are 
authorized  after  identity,  authentication  continues  throughout  a  work 
session. 


Checklist 

YES 

KD 

N/A 

5.7.3.1  Classified  data  protection. 

a)  When  displayed  data  are  classified  for  security  purposes,  a 
prominent  indication  of  security  classification  is  presented  in  each 
display. 

b)  When  classified  information  is  displayed,  some  rapid  means 
for  suppressing  a  display  is  provided. 

c)  Procedures  to  control  access  to  printed  or  printing  data  is 
provided  rather  than  prohibiting  the  printing  of  classified  information. 

d)  When  sensitive  data  may  be  exposed  to  unauthorized  access,  a 
capability  for  encrypting  data  is  provided. 

e)  Data  encryption  is  easily  reversible. 

5.7.3.2  Record/loo  keeping. 

a)  The  computer  automatically  keeps  records/logs  of  data  access. 

b)  Users  are  not  relied  on  to  take  aitical  record  keeping  actions. 

c)  Transaction  records  and  logs  are  stamped  with  user 
identifiers,  time,  and  date. 

d)  Provisions  are  made  to  control  requests  for  records  and  logs  of 
data  transactions  with  classified  material. 

e)  Users  are  informed  concerning  the  nature  and  purpose  of 
automated  recording  of  individual  actions. 

f)  When  multiple  users  review,  enter,  or  modify  data  in  a 
system,  they  are  able  to  review  and  browse  data  changes  or  entries  made 
by  other  users. 

5.7 .3 .3  Data  preservation. 


a)  When  protection  of  displayed  data  is  essential,  the  computer 
maintains  control  over  the  display  and  does  not  permit  a  user  to  change 
"read-only"  data. 

b)  A  "read-only"  status  is  indicated  for  users  not  authorized  to 
change  displayed  data. 


Checklist 


YES 


c)  Provisions  are  made  to  prevent  accidental  activation  of 
potentially  destructive  control  actions. 

d)  When  required,  display  formatting  features,  such  as  field 
labels  and  delimiters,  are  protected  from  change  by  users. 

e)  If  a  complete  file  is  to  be  deleted,  sufficient  information,  is 
displayed  to  verify  the  file  for  deletion. 

f)  Users  are  required  to  confirm  destructive  entries. 

g)  The  prompt  for  a  CONFIRM  action  warns  users  explicitly  of 
any  possible  data  loss. 

h)  An  explicitly  labeled  CONFIRM  function  key,  different  from 
the  ENTER  key  is  provided  for  user  confirmation  of  critical  control  and 
data  entries. 

i)  Data  loss  at  LOG  OFF  is  avoided  by  a  check  on  pending 
transactions  and  display  of  an  advisory  message  requesting  user 
confirmation. 

i 

j)  When  two  or  more  users  have  simultaneous  read  access  or  data 
processing  results  from  multiple  user-computer  interfaces,  the 
operation  by  one  person  does  not  interfere  with  the  operations  of  another 
person,  unless  mission  survival  may  be  contingent  upon  the  preemption. 

k)  Provisions  are  made  so  that  the  preempted  user  can  resume 
operations  at  the  point  of  interference,  without  information  loss. 

5. 7. 3. 4  Data  entrv/chanae.  Procedures  for  data  entry  and  change  follow 
guidelines  presented  in  Sections  5.2  "Data  Entry",  5.1 
"Dialogs/Interaction  Control,  and  5.3  "Data  Display". 


YES  ND  N/A 


5.7.4. 1  System  control. 

a)  Measures  provided  to  protect  data  during  transmission  are 
applied  automatically,  without  the  need  for  user  action. 

b)  A  copy  of  any  transmitted  message  is  automatically  saved  until 
correct  receipt  has  been  confirmed. 

c)  As  necessary,  automatic  queuing  of  incoming  messages  are 
provided  to  ensure  they  do  not  disrupt  current  classified  information 
handling  tasks. 

5.7.4.2  User  actions. 


a)  When  a  user  must  confirm  the  identity  of  a  message  source, 
computer  aids  such  as  computer-generated  confirmation  codes  are 
provided  for  that  purpose. 

b)  When  human  judgment  may  be  required  to  determine  whether 
data  are  appropriate  for  transmission,  users  or  a  system  administrator 
are  provided  means  to  review  outgoing  messages  and  confirm  release 
before  transmission. 
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